Концепция групп администрирования
Группы администрирования используются для определения административной топологии в больших организациях с множеством филиалов, подразделений, отделов, серверов Exchange и администраторов Exchange. Эти группы по своей природе являются логическими, то есть можно определить группу по географическому местоположению, подразделению, отделу или выполняемой функции. Например, если у компании 14 офисов в 14 странах, то в каждом из них, скорее всего, понадобится один или несколько серверов Exchange, причем должен присутствовать и администратор Exchange. В данной ситуации, вероятно, лучше всего создать группу администрирования для каждого из 14 мест, чтобы локальный администратор Exchange осуществлял управление локальными серверами Exchange. Другим возможным вариантом является выполнение всех функций группы маршрутизации одной группой, другая группа осуществляет выполнение всех функций, связанных с общими папками, а третья группа предназначена для поддержки всех функций
системной политики. При использовании групп администрирования члены более крупной группы администрирования Exchange могут специализироваться в одной области администрирования, даже если рассматриваемая организация Exchange является всемирной.
Группа администрирования упрощает присвоение полномочий администрирования. После установки разрешений для объекта группы администрирования любые объекты, созданные или перемещенные в объект, наследуют полномочия родительского объекта. Следовательно, проще всего сначала установить разрешения для группы администрирования, а потом создать объекты внутри группы, чтобы они унаследовали полномочия группы. Как всегда, рекомендуется устанавливать разрешения на уровне самого верхнего объекта и затем распространять полномочия вниз по объектной иерархии. Объекты, создаваемые в группе администрирования, включают в себя следующие элементы.
Серверы.
Группы маршрутизации.
Деревья общих папок.
Системные политики.
Выбор модели администрирования
Для организации групп администрирования используется одна из трех моделей администрирования: централизованная, децентрализованная и смешанная. В рамках обсуждаемой здесь темы будет создана вымышленная компания под названием Trains By Dave. Компания Trains By Dave имеет семь офисов в трех регионах, как показано на рис 12.1.
(рис 12.1) Компания Trains By DaveЦентрализованная модель администрирования
В централизованной модели администрирования одна группа поддерживает полный набор функций управления всеми серверами Exchange. Может существовать только одна группа или несколько строго контролируемых групп, предназначенных для целей администрирования. Топология группы маршрутизации не обязательно должна совпадать с топологией администрирования, поэтому может присутствовать несколько групп маршрутизации, отражающих физическую топологию сети, в то время как централизованный контроль администрирования осуществляется в одной группе администрирования. На рисунке 12.2 показано, как данная структура применена в компании Trains By Dave.
(рис 12.2) Централизованная модель администрированияПримечание. Факт наличия между всеми географически отдаленными местоположениями высокоскоростного канала связи никак не влияет на модель администрирования. Все серверы могли бы располагаться в одной группе администрирования, даже если бы канал обеспечивал скорость лишь 8 Кбит/с.
Децентрализованная модель администрирования
В децентрализованной модели администрирования в каждом местоположении есть своя команда администраторов Exchange, которые осуществляют административный контроль над всеми объектами, располагаемыми внутри их группы администрирования. Эти группы часто базируются на географических местоположениях или на структуре подразделений компании. Каждая из групп содержит политики, серверы, деревья общих папок и другие объекты, специфичные для группы. На рисунке 12.3 показано, как это реализовано в компании Trains By Dave. Здесь понадобится создать группу администрирования для каждого из трех континентов, а также потребуется наличие группы администраторов Exchange, каждый из которых отвечает за поддержку серверов Exchange в своей географической зоне.
Если осуществляется переход с версии Exchange Server 5.5, и перед этим существовало несколько сайтов в организации Exchange 5.5, во время перехода придется использовать децентрализованную модель администрирования. Каждый сайт Exchange 5.5 будет создан как отдельная группа администрирования в Exchange Server 2003.
(рис 12.3) Децентрализованная модель администрированияЧтобы одновременно централизовать администрирование серверов Exchange 2003 и серверов Exchange 5.5, необходимо указать для административных групп полномочия доступа, ограничивающие администрирование групп только теми лицами, которые будут указаны. Это не приведет к включению серверов Exchange 5.5 в одну административную группу, но ограничит администрирование одной группой администраторов. Единственным способом реализации централизованной модели является миграция всех серверов Exchange 5.5 в систему Exchange Server 2003.
Примечание. Собственный режим означает, что в сети уже нет серверов Exchange более старых версий (т.е. на всех серверах функционирует система Exchange 2000 Server или Exchange Server 2003). Собственный режим для Exchange Server 2003 используется отдельно и отличается от собственного режима Microsoft Windows 2000 и более высоких функциональных уровней Windows Server 2003. Для получения подробной информации об этом режиме (что он означает и как действует в Exchange Server 2003) обратитесь к лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
Смешанная модель администрирования
Смешанная модель администрирования лучше всего подходит для того, чтобы ограничить выполнение определенных административных функций определенной группой людей, не создавая при этом специализаций для каждой административной функции. В данной модели создаются административные группы по функциям, а не по географическому местоположению или границам подразделений компаний. Например, можно создать группу администрирования, единственным дочерним объектом которой являются политики. В такой ситуации можно ограничить право создавать новые политики или изменять существующие политики для организации Exchange небольшой группой людей. Однако другие административные функции останутся под управлением принятой по умолчанию административной группы First Administrative Group (Первая группа администрирования), и они не будут включены в их собственную административную группу.
Данную модель можно также использовать для объединения специализированных административных функций и распределения по географическому принципу в одну административную модель. Например, создать одну административную группу для управления маршрутными группами, вторую группу – для управления политиками, третью группу – для подразделения Atlantic, четвертую группу – для отдела European и пятую группу – для управления всеми деревьями общих папок. На рисунке 12.4 показано, как это будет выглядеть для компании Trains By Dave, где сохранена децентрализованная модель для ежедневного администрирования, но используется централизованная модель, объединяющая деревья общих папок в одну административную группу и политики в другую административную группу.
(рис 12.4) Смешанная модель администрирования
Группы администрирования и полномочия доступа
Полномочия в Exchange Server 2003 базируются на модели полномочий доступа Active Directory. Это означает, что присвоение пользователю или группе полномочий доступа осуществляется по объекту, дочернему объекту или классу объектов.
Объект в Active Directory после создания наследует по умолчанию полномочия родительского объекта. Наследование позволяет распространять полномочия вниз по иерархии объектов, поэтому нет необходимости вручную присваивать дочернему объекту его полномочия. Кроме того, чтобы изменить полномочия для целого диапазона объектов, нужно всего лишь изменить эти полномочия для родительского объекта, а дочерние объекты автоматически унаследуют эти полномочия.
Модель присваивания полномочий доступа в Exchange Server 2003 обеспечивает контроль администраторов над распространением полномочий на контейнеры и объекты. Этот контроль осуществляется посредством специализированного наследования, которое позволяет указывать, что только определенные объекты наследуют полномочия. Вы можете задать наследование для следующих элементов:
только данный объект;
только наследник;
данный объект и вложенные контейнеры;
данный объект и дочерние объекты;
только вложенные контейнеры;
только дочерние объекты;
данный объект, вложенные контейнеры и дочерние объекты;
вложенные контейнеры и дочерние объекты.
Пример из практики.Как происходит распространение полномочий в разделе именования конфигурации
По умолчанию члены группы Enterprise Admins (Администраторы предприятия) имеют полный контроль над административными группами. Группа Domain Admins (Администраторы домена) тоже имеет существенные полномочия по этим объектам. На рисунке 12.5 показано окно консоли интерфейса служб Active Directory (ADSI Edit), из которого видно, как происходит наследование полномочий из контекста конфигурации (ADSI Edit – это оснастка MMC.)
Поскольку Exchange Server 2003 содержит значительную часть своей информации в разделе конфигурации Active Directory, организация Exchange создается именно в этом разделе. С точки зрения службы Active Directory, объект организации – это просто еще один объект, на который распространяются принятые по умолчанию полномочия доступа.
Если рассматриваемая среда устроена таким образом, что существует резкое отличие между деятельностью администраторов Exchange и администраторов доменов, то потребуется создать группу Exchange Admins (Администраторы Exchange) и предоставить этой группе полный контроль над всеми аспектами организации Exchange, а также ограничить глубину и объем полномочий для группы Domain Admins (Администраторы домена). Это необходимо сделать вручную в самом объекте-организации. Кроме того, потребуется блокировать наследование полномочий из раздела конфигурации Active Directory и переназначить полномочия на уровне организации для всех объектов Exchange Server.
(рис 12.5) Консоль ADSI Edit с отображением наследования полномочий для административных групп
Дополнительная информация. Подробнее о том, как блокировать наследование полномочий, рассказано в книге Microsoft Windows 2003 Security Administrator's Companion (автор Roberta Bragg, издательство Microsoft Press).
Создание группы администрирования
Поскольку Exchange Server 2003 устанавливается во многих компаниях небольшого и среднего масштаба, интерфейс Administrative and Routing Group (Группы администрирования и маршрутизации) отключен по умолчанию. Чтобы увидеть эти группы, перейдите в окно вкладки General (Общие) окна свойств организации (см. рис 12.6) и в области Administrative Views (Административные просмотры) включите опцию Display Routing Groups (Отображать маршрутные группы) и опцию Display Administrative Groups (Отображать административные группы), согласно надобности.
(рис 12.6) Включение интерфейса Administrative and Routing GroupПримечание. Хотя на рисунке 12.6 показан интерфейс в собственном режиме (native mode), эти конфигурации можно выбрать в смешанном режиме. Нет необходимости находиться в собственном режиме, чтобы отобразить группы маршрутизации и администрирования.
Следует отметить, что если сервер Exchange 2003 инсталлирован в существующем сайте Exchange 5.5, то интерфейс Administrative and Routing Group активизирован по умолчанию. Каждый сайт Exchange 5.5 отображается в оснастке Exchange System в виде отдельной административной группы. Для получения дополнительной информации о совместном использовании серверов Exchange 2003 и Exchange 5.5 обратитесь к лекции 3 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
После активизации интерфейса групп администрирования и маршрутизации можно начать установку административных групп. Для этого откройте оснастку Exchange System, щелкните правой кнопкой мыши на контейнере Administrative Groups (Группы администрирования), наведите указатель мыши на пункт New (Создать) и выберите пункт Administrative Group (Группа администрирования). На рисунке 12.7 показано окно свойств, в котором будет осуществляться работа. Введите имя создаваемой административной группы, введите нужные примечания в окне вкладки Details (Дополнительно), после чего будет создана группа администрирования.
(рис 12.7) Страница свойств новой группы администрированияПосле создания группы администрирования следует перейти к созданию дочерних объектов для этой группы. По умолчанию в группе не создается никаких объектов. Если щелкнуть правой кнопкой мыши на группе, появится контекстное меню, с помощью которого можно создать три новых контейнера:
контейнер Routing Groups (Маршрутные группы);
контейнер System Policy (Системная политика);
контейнер Public Folders (Общие папки).
Создание нового контейнера
Чтобы создать новый контейнер, который будет контролироваться данной группой администрирования, выберите нужный тип контейнера в контекстном меню (рис 12.8). После этого внутри данной группы будет создан соответствующий контейнер. При создании контейнеров на экране не появится какое-либо окно мастера. Также станет видно, что нет надобности в установке каких бы то ни было свойств, поскольку это просто контейнер. Этот объект можно рассматривать как блок, который содержит другие блоки, ни больше и не меньше. По мере создания групп маршрутизации для них будут указываться реальные свойства.
Примечание. На рисунке 12.8 показаны три опции для выбора, но иногда будут отображаться только две опции. Опция создания контейнера общих папок не появится на экране, если это новая группа администрирования, и внутри нее еще не создано других контейнеров. После создания нового контейнера, такого как Routing Groups, при создании второго контейнера будет видно, что в списке появилась опция Public Folders Container (Контейнер общих папок). Опция создания контейнера общих папок также не появится в списке, если уже создан контейнер этого типа, поскольку для каждой группы администрирования требуется только один контейнер общих папок.
(рис 12.8) Контекстное меню новой группы администрирования с отображением типов контейнеров, которые могут быть созданы
Объекты сервера и группы администрирования
В Exchange Server 2003 серверы всегда устанавливаются по умолчанию в группе First Administrative group внутри контейнера Server (Сервер). (First Administrative group [Первая группа администрирования] – это имя по умолчанию; его можно изменить в соответствии с соглашением об именовании групп администрирования. Для этого следует щелкнуть на имени правой кнопкой мыши.) Отметим, что нельзя создать контейнер серверов внутри новой группы администрирования и затем перемещать в нее серверы из группы First Administrative group. Эта особенность обусловлена структурой Exchange Server.
При создании новой группы администрирования автоматически создается контейнер Servers (Серверы) для этой группы, но он не отображается в оснастке Exchange System. Это видно на примере группы администрирования Hawaii. Если посмотреть на эту группу администрирования в окне оснастки Active Directory Sites and Services (Active Directory –сайты и службы), работающей в режиме Show Services (Отображение служб), то станет видно, что в группе Hawaii Admin group создан контейнер серверов (Servers) и контейнер Advanced Security (Дополнительная защита), несмотря на то что эти контейнеры не отображаются в окне оснастки Exchange System. Однако после установки сервера в группе администрирования этот объект-сервер появится в окне оснастки Exchange System. Поэтому необходимо создать группы администрирования до начала инсталляции серверов Exchange 2003, если планируется использовать эти серверы в нескольких группах администрирования.
(рис 12.9) Объект сервера группы администрирования Hawaii Admin group в окне оснастки Active Directory Sites and Services
Политики Exchange 2003
Политики в Exchange Server 2003 предназначены для повышения гибкости администрирования при одновременном снижении нагрузки на администраторов. Политика – это набор параметров конфигурирования, которые применяются к одному или нескольким объектам одного класса в Exchange. Например, можно создать политику, которая воздействует на определенные параметры некоторых или всех серверов Exchange. Если потребуется изменить эти параметры, то достаточно модифицировать эту политику, и она будет применена к соответствующей организации сервера.
Существует два вида политик: системная политика (system policy) и политика получателей (recipient policy). Политики получателей применяются к объектам с доступом к почте и указывают, каким образом генерируются адреса электронной почты. Речь о политиках получателей идет в ).
(рис 12.10) Объект "системная политика"Примечание. При установке Exchange Server 2003 не создается контейнер по умолчанию для системных политик. Его необходимо создать перед построением системных политик. Щелкните правой кнопкой мыши на группе администрирования, в которой требуется создать папку политики, наведите указатель мыши на пункт New (Создать) и выберите System Policy Container (Контейнер системной политики).
Создание системной политики
Для создания системной политики нужно перейти в соответствующий контейнер System Policies (Системные политики), щелкнуть правой кнопкой мыши на контейнере, после чего выбрать тип создаваемой политики: политика сервера, политика хранилища почтовых ящиков или политика хранилища общих папок.
При работе с системными политиками не забудьте создать объектполитику в группе, которая несет ответственность за администрирование этой политики. Иначе может произойти ошибка в выборе людей, которые осуществляют административный контроль за критически важными политиками. Рассмотрим, как создается каждый из трех типов политик, начиная с политик серверов.
Создание политики серверов
Политика серверов определяет параметры отслеживания сообщений и обслуживания файлов журналов. Она не применяется к параметрам безопасности или другим параметрам серверов в данной группе администрирования. Чтобы создать политику серверов, щелкните правой кнопкой мыши на контейнере System Policies (Системные политики), укажите на пункт New (Создать) и затем выберите вариант Server Policy (Политика серверов). Появится диалоговое окно New Policy (Создание политики), показанное на рис 12.11, в котором указываются вкладки, отображаемые на странице свойств данной политики. Для политики серверов имеется только одна опция: вкладка General (Общие). Отметьте опцию для этой вкладки и затем нажмите OK. Отобразится окно конфигурирования, в котором будет создана данная политика.
(рис 12.11) Диалоговое окно New Policy (Создание политики)После этого нужно ввести имя политики в окне вкладки General страницы свойств данной политики. Как показано на рисунке 12.12, на самом деле существует две вкладки General. Первая вкладка используется для ввода имени политики. Выберите имя для описания задачи, для выполнения которой предназначена данная политика, например Message Tracking Policy (Политика отслеживания сообщений) или Enable Subject Logging Policy (Политика "Активизировать регистрацию тем сообщений"). Подходящее имя, выбранное на этой стадии, сэкономит время работы, так как не будет необходимости открывать страницу свойств этой политики, чтобы определить ее назначение.
Вкладка General (Policy) (Общие [Политика]), показанная на рис 12.13, содержит реальные параметры политики, применяемые к серверам Exchange рассматриваемой организации. Вкладка называется General (Policy), так как потенциально осуществляется конфигурация вкладки General страниц свойств для всех имеющихся серверов. (Ниже в этой лекции мы рассмотрим, как применять эту политику ко всем серверам организации.) Если сравнить эту вкладку с вкладкой General на странице свойств какого-либо сервера, то станет видно, что эти вкладки совпадают, за исключением идентифицирующей информации вверху вкладки.
На вкладке General (Policy) активизируется регистрация и отображение на экране тем сообщений (Enable subject logging and display) для всех имеющихся серверов Exchange 2003. Эта установка действует в сочетании с опцией Enable Message Tracking (Активизировать отслеживание сообщений), что позволяет отслеживать сообщения, передаваемые в организации. Эти опции полезны для поиска и устранения источника проблем, возникающих, когда некоторые пользователи не получают сообщений от других пользователей. Существует возможность отслеживания прохождения сообщения через организацию для определения места, в котором имеются проблемы с передачей данных. Подробнее об отслеживании сообщений и регистрации тем сообщений рассказывается в лекции 6 "Функциональность, безопасность и поддержка Exchange Server 2003".
(рис 12.13) Ввод имени политики в окне вкладки General(рис 12.12) Вкладка General (Policy)После того как политика начала действовать, ее нельзя изменить на уровне локальных серверов. Политика отслеживания сообщений, которую мы использовали в качестве примера, была сформирована на сервере EX-SRV1 в группе администрирования Arizona. На рисунке 12.14 показано, что параметры отслеживания сообщений недоступны для изменения на странице свойств сервера EX-SRV1, поскольку эти значения определены политикой.
(рис 12.14) Окно свойств сервера EX-SRV1 с недоступными (затененными) параметрами отслеживания сообщений (Message tracking)На данном этапе, скорее всего, вы хотели бы узнать, как мы применили политику к этим трем серверам. Чтобы применить политику после ее создания, выполните следующие шаги. Щелкните правой кнопкой мыши на новой политике, после чего выберите Add Server (Добавить сервер). Появится диалоговое окно, позволяющее указать комбинацию серверов в организации Exchange. После создания политики ее можно применить к любой комбинации серверов в рассматриваемой организации Exchange. После выбора серверов нажмите OK, и политика будет применена к указанным серверам. Чтобы проверить это, выделите созданный объект-политику в окне оснастки Exchange System. Добавленные серверы отобразятся справа в окне детализованной информации (см. рис 12.15).
Чтобы удалить сервер из списка политики, перейдите в объект-политику данного сервера в окне оснастки Exchange System. В окне детализированной информации выделите сервер, который требуется удалить. Щелкните правой кнопкой мыши на этом сервере и выберите пункт Remove From Policy (Удалить из политики).
(рис 12.15) Серверы, к которым применяется выбранная политикаЕсли в существующую политику вносятся изменения после того, как были сохранены прежние изменения, на экране появится окно с предложением немедленно применить изменения в политике ко всем объектам. На выбор предлагаются опции Yes (Да) или No (Нет). Выбор Yes означает, что данная политика будет немедленно применена к соответствующим объектам. Ответ No, означает, что изменения политики будут применяться через обычные периоды репликации.
Создание политики хранилищ общих папок
Политики хранилищ общих папок определяют ряд параметров конфигурации, включая расписания технического обслуживания, пределы хранения элементов и индексирование по всему тексту. Они применяются к каждому хранилищу в границах дерева общих папок.
Процедура создания политик хранилищ общих папок аналогична процедуре создания политики серверов, описанной в предыдущем разделе. Однако здесь есть возможность указать пять вкладок для страницы свойств политики хранилищ общих папок.
General (Policy) (Общие [Политика]). Здесь активизируется поддержка стандарта S/MIME (Secure/Multipurpose Internet Mail Extensions – защищенные/многоцелевые почтовые расширения интернета) и указывается необходимость преобразования текста в формат шрифта с фиксированным размером (10-точечный Courier).
Database (База данных). На данной вкладке указывается, нужно ли выполнять ежедневное техническое обслуживание общих папок.
Replication (Репликация). Определяет, насколько часто должна происходить репликация общих папок, а также предельный размер репликации и интервал репликации (в минутах) при использовании опции Always (Всегда).
Full-Text Indexing (Индексирование по всему тексту). Определяет интервал модификации и интервал полного обновления индекса для общих папок.
)
Более подробно о параметрах хранилища общих папок рассказывается в лекции 10.
(рис 12.16) Вкладка Limits (Policy) страницы свойств для политики хранилищ общих папокЧтобы применить политику к общим папкам, ее нужно связать с ними точно так же, как это было сделано с политикой серверов в предыдущем разделе. По умолчанию никакая политика не применяется к предполагаемому объекту этой политики; необходимо связать (ассоциировать) ее с этим объектом, выбрав пункт Add Public Store (Добавить общее хранилище) в контекстном меню данной политики.
В отличие от политики серверов, которые содержат только одну вкладку на своих страницах свойств, политика хранилищ общих папок содержит до семи вкладок. Это не означает, что необходимо использовать все эти вкладки. Если требуется добавить или удалить вкладки в существующей политике хранилищ общих папок, то для этого достаточно щелкнуть правой кнопкой мыши на политике и выбрать пункт Change Property Pages (Изменить страницы свойств). Затем следует выбрать вкладки, которые нужно добавить или удалить, и сконфигурировать их нужным образом.
Создание политики хранилищ почтовых ящиков
Политика хранилищ почтовых ящиков позволяет настраивать ряд параметров для почтовых ящиков, включая принятое по умолчанию хранилище почтовых ящиков, график технического обслуживания, получателя, который ведет журнал сообщений (то есть получает копии всех сообщений электронной почты, проходящих через организацию), и индексирование по всему тексту. При создании политики хранилищ почтовых ящиков в страницу свойств этой политики включаются вкладки General (Общие), Database (База данных), Limits (Пределы хранения) и Full-Text Indexing (Индексирование по всему тексту).
Примечание. Ведение журнала сообщений (message journaling) – это концепция, которая введена в пакете обновления Service Pack 1 для Exchange 5.5. По существу это отправка копий большинства сообщений электронной почты общему получателю для последующего использования в юридических или государственных целях. Это средство чаще всего активизируется в тех случаях, когда компания вынуждена сохранять все свои сообщения электронной почты в соответствии с государственными правилами или в юридических целях.
На вкладке General (Policy) указывается используемое по умолчанию хранилище общих папок для хранилищ почтовых ящиков, которые будут связаны (ассоциированы) с этой политикой. Это очень удобно, если требуется создать большое число хранилищ общих папок и ассоциировать большинство (или все) хранилищ с определенным хранилищем общих папок. На вкладке General (Policy) также указывается используемый по умолчанию автономный список адресов (Default offline address list), который будет применяться в выбранных хранилищах почтовых ящиков. Также существует возможность указать архивирование сообщений в этом хранилище. Кроме того, можно активизировать клиентскую поддержку электронных подписей в стандарте S/MIME, а также включить использование шрифта с фиксированным размером для всех поступающих сообщений.
Единственный элемент, указываемый на вкладке Database (Policy), – время ежедневного технического обслуживания. Если также создается политика хранилищ общих папок, то необходимо предусмотреть, чтобы у этих политик время технического обслуживания различалось, чтобы повысить производительность системы при выполнении процедуры оперативного технического обслуживания. Планируя свою работу, предусмотрите дополнительные процедуры, которые будут выполняться во время простоя, включая программы резервного копирования, дефрагментацию базы данных и репликацию.
Примечание. К основным действиям, выполняемым с хранилищем в целях технического обслуживания, относятся: проверка существования нужных папок Free/Busy и папок автономных адресных книг для группы администрирования и, если эти папки не существуют, их создание; стирание индексов базы данных, которые были созданы раньше, но в последнее время не используются; стирание тех элементов, у которых истекло время хранения удаленных элементов (это называется окончательным удалением); удаление элементов общих папок, у которых истек срок старения; стирание удаленных из хранилища почтовых ящиков, у которых превышен окончательный срок хранения; выявление почтовых ящиков, не связанных с каким-либо объектом-пользователем, а также выявление почтовых ящиков, которые повторно связаны с каким-либо пользователем.
На вкладке Limits (Policy), показанной на рис 12.17, устанавливаются пределы хранения и параметры удаления. Определяя предельный размер почтового ящика, можно включать уведомление службой System Attendant пользователей о том, что они превысили этот предел. Используйте кнопку Customize (Настроить), чтобы создать специализированный график, позволяющий устанавливать несколько моментов времени в течение суток, когда пользователи, превысившие предельные размеры своих почтовых ящиков, будут получать уведомления о том, что они должны предпринять какие-то действия для уменьшения размера своих почтовых ящиков.
(рис 12.17) Вкладка Limits (Policy) страницы свойств политики хранилищ почтовых ящиковПолитика хранилищ почтовых ящиков применяется на уровне хранилищ, но не на уровне групп хранения или серверов. Кроме того, необязательно монтировать хранилище так, чтобы его можно было ассоциировать с определенной политикой. Более подробно о параметрах хранилища почтовых ящиков рассказывается в лекции 11.
Разрешение конфликтов политик
Когда две различные политики применяются к одному объекту, возможен конфликт между этими политиками. В этом случае принято по умолчанию, что более поздняя политика замещает более раннюю политику. Но при включенной опции Do Not Allow The Removal Of This Policy From The Items It Applies To (Не разрешается удалять эту политику из элементов, к которым она применяется) более поздняя политика не сможет заменить более раннюю, и отобразится сообщение о том, что данный объект находится под контролем конфликтующей политики. Далее появится запрос о выводе данного объекта из-под контроля конфликтующих политик. Если выбрать Yes (Да), то будет применена новая политика, а если выбрать No (Нет), то будет сохранена старая политика.
Создание и администрирование групп маршрутизации
Как мы уже говорили, группа администрирования – это набор объектов, которые сгруппированы таким образом, чтобы осуществлять объединенное администрирование этих объектов. В отличие от нее группа маршрутизации – это набор серверов, между которыми обеспечивается постоянное соединение с высокой пропускной способностью. Предполагается, что каналы между группами маршрутизации являются медленными или ненадежными. Для соединения групп маршрутизации через эти медленные каналы глобальной сети используются коннекторы. Таким образом, группы администрирования являются логическими по своей природе, в то время как группы маршрутизации определяются физической топологией сети.
Группы маршрутизации позволяют указывать маршруты, по которым будут проходить сообщения от отправителя к получателю внутри организации. Используя значения стоимостей, применяемые на коннекторах, можно задавать преимущественный физический маршрут прохождения сообщений в организации. Подробнее об архитектуре групп маршрутизации рассказывается в лекции 3.
Создание группы маршрутизации
Создание групп потребуется в том случае, если имеется два или больше серверов, соединенных медленным или ненадежным каналом глобальной сети. Группы маршрутизации создаются в смешанном или в собственном режиме. Границы групп маршрутизации необязательно должны соответствовать границам групп администрирования в собственном режиме, но в смешанном режиме они не могут охватывать несколько административных групп. Это ограничение обуславливается способом взаимодействия Exchange 5.5 с Exchange Server 2003. Пока Exchange Server 2003 находится в смешанном режиме, он сохраняет способность взаимодействия с Exchange 5.5. А поскольку в Exchange 5.5 нельзя перемещать серверы между сайтами, то не существует возможности перемещать их между группами маршрутизации или администрирования в Exchange Server в смешанном режиме.
Группы маршрутизации создаются внутри контейнера Routing Groups (Группы маршрутизации). Если конкретная ситуация позволяет сделать это, то новые контейнеры Routing Groups могут создаваться в других группах администрирования. В каждой группе администрирования может быть создан только один контейнер Routing Groups, но в каждом контейнере Routing Groups можно создать несколько групп маршрутизации.
Чтобы создать группу маршрутизации, щелкните правой кнопкой мыши на контейнере Routing Groups, укажите на пункт New (Создать) и затем выберите опцию Routing Group (Группа маршрутизации). Введите имя новой группы маршрутизации на вкладке General и нажмите OK.
Новая группа маршрутизации состоит из двух дочерних объектов – Connectors (Коннекторы) и Members (Члены) (см. рис 12.18). В контейнере Connectors будут создаваться коннекторы Routing Group Connectors (подробнее об этом рассказывается в лекции 13), а в контейнере Members будут размещаться объекты-серверы, являющиеся членами группы маршрутизации.
Если необходимо подсоединиться к внешней системе электронной почты, то это можно сделать путем установки коннектора X.400 Connector или SMTP Connector (как правило, первого из них). (О том, как подсоединиться к внешней системе, рассказывается в лекции 1 "Функциональность, безопасность и поддержка Exchange Server 2003"). Эти коннекторы также используются для соединения групп маршрутизации внутри рассматриваемой организации, но лучше взять для этой цели Routing Group Connector (Коннектор групп маршрутизации). RGC можно использовать только внутри организации для соединения групп маршрутизации. Его нельзя использовать для соединения с внешней системой электронной почты.
Управление группой маршрутизации
Две из наиболее важных задач в администрировании маршрутной группы – это создание новых групп маршрутизации и добавление одного или нескольких серверов к группе маршрутизации. Добавляя сервер к группе маршрутизации, системе Exchange Server 2003 фактически сообщается о том, что добавляемый сервер имеет постоянную возможность соединения с другими серверами данной группы с высокой пропускной способностью. Несмотря на то что не существует минимального предела пропускной способности, жестко установленного в операционной системе Exchange, рекомендуется абсолютный минимум 64 Кбит/с при постоянной возможности соединения.
(рис 12.18) Объекты в новой группе маршрутизацииПримечание. Не забудьте проверить имеющиеся каналы глобальной сети (WAN), прежде чем начать реализацию Exchange Server 2003. Выделенная линия со скоростью 64 Кбит/с, возможно, обеспечивает более постоянную пропускную способность, чем линия T1, которая часто насыщена трафиком, не относящимся к Exchange. Имеет смысл принять в расчет другие виды трафика по каналам глобальной сети и затем использовать остающуюся часть пропускной способности, чтобы оценить, хватает ли этого для обеспечения постоянного соединения с высокой пропускной способностью.
Чтобы добавить сервер к группе маршрутизации, найдите и выделите контейнер Members группы маршрутизации, которой принадлежит в данный момент этот сервер (по умолчанию это First Routing Group). Перетащите этот сервер в контейнер Members нужной группы маршрутизации.
Примечание. При перемещении сервера из какой-либо группы маршрутизации фактически происходит перемещение виртуального сервера SMTP или службы X.400, с помощью которой этот сервер осуществляет взаимодействие, причем эта служба повторно создается в новой группе маршрутизации.
По умолчанию все серверы, созданные в новой организации, принадлежат группе First Routing Group (Первая группа маршрутизации), используемой по умолчанию, которая создается при первоначальной инсталляции Exchange Server 2003. Однако вполне возможно, что потребуются дополнительные группы маршрутизации, согласно физической топологии сети.
Чтобы переименовать объект "группа маршрутизации", щелкните правой кнопкой мыши на данной группе маршрутизации, выберите пункт Rename (Переименовать) и введите новое имя. Чтобы удалить группу маршрутизации, необходимо сначала переместить в другие группы маршрутизации все серверы, которые входят в удаляемую группу маршрутизации. Нельзя удалить группу маршрутизации, в которой находятся объекты-серверы, включенные в контейнер Members. Переместив все серверы, щелкните правой кнопкой мыши на данной группе маршрутизации и выберите пункт Delete (Удалить). Нажмите Yes (Да), чтобы подтвердить удаление группы маршрутизации.
Заключение
В данной лекции рассказывалось о том, как создавать и осуществлять управление группами администрирования и маршрутизации. Когда речь идет о группах маршрутизации, контейнеры сами по себе не представляют сложности в управлении. Тем не менее, не всегда легко создавать коннекторы между группами маршрутизации и осуществлять управление ими, и данная задача нередко усложняет работу администратора. В следующей лекции мы уделим внимание вопросам, связанным с коннекторами групп маршрутизации.
Концепция групп администрирования
Группы администрирования используются для определения административной топологии в больших организациях с множеством филиалов, подразделений, отделов, серверов Exchange и администраторов Exchange. Эти группы по своей природе являются логическими, то есть можно определить группу по географическому местоположению, подразделению, отделу или выполняемой функции. Например, если у компании 14 офисов в 14 странах, то в каждом из них, скорее всего, понадобится один или несколько серверов Exchange, причем должен присутствовать и администратор Exchange. В данной ситуации, вероятно, лучше всего создать группу администрирования для каждого из 14 мест, чтобы локальный администратор Exchange осуществлял управление локальными серверами Exchange. Другим возможным вариантом является выполнение всех функций группы маршрутизации одной группой, другая группа осуществляет выполнение всех функций, связанных с общими папками, а третья группа предназначена для поддержки всех функций
системной политики. При использовании групп администрирования члены более крупной группы администрирования Exchange могут специализироваться в одной области администрирования, даже если рассматриваемая организация Exchange является всемирной.
Группа администрирования упрощает присвоение полномочий администрирования. После установки разрешений для объекта группы администрирования любые объекты, созданные или перемещенные в объект, наследуют полномочия родительского объекта. Следовательно, проще всего сначала установить разрешения для группы администрирования, а потом создать объекты внутри группы, чтобы они унаследовали полномочия группы. Как всегда, рекомендуется устанавливать разрешения на уровне самого верхнего объекта и затем распространять полномочия вниз по объектной иерархии. Объекты, создаваемые в группе администрирования, включают в себя следующие элементы.
Серверы.
Группы маршрутизации.
Деревья общих папок.
Системные политики.
Выбор модели администрирования
Для организации групп администрирования используется одна из трех моделей администрирования: централизованная, децентрализованная и смешанная. В рамках обсуждаемой здесь темы будет создана вымышленная компания под названием Trains By Dave. Компания Trains By Dave имеет семь офисов в трех регионах, как показано на рис 12.1.
(рис 12.1) Компания Trains By DaveЦентрализованная модель администрирования
В централизованной модели администрирования одна группа поддерживает полный набор функций управления всеми серверами Exchange. Может существовать только одна группа или несколько строго контролируемых групп, предназначенных для целей администрирования. Топология группы маршрутизации не обязательно должна совпадать с топологией администрирования, поэтому может присутствовать несколько групп маршрутизации, отражающих физическую топологию сети, в то время как централизованный контроль администрирования осуществляется в одной группе администрирования. На рисунке 12.2 показано, как данная структура применена в компании Trains By Dave.
(рис 12.2) Централизованная модель администрированияПримечание. Факт наличия между всеми географически отдаленными местоположениями высокоскоростного канала связи никак не влияет на модель администрирования. Все серверы могли бы располагаться в одной группе администрирования, даже если бы канал обеспечивал скорость лишь 8 Кбит/с.
Децентрализованная модель администрирования
В децентрализованной модели администрирования в каждом местоположении есть своя команда администраторов Exchange, которые осуществляют административный контроль над всеми объектами, располагаемыми внутри их группы администрирования. Эти группы часто базируются на географических местоположениях или на структуре подразделений компании. Каждая из групп содержит политики, серверы, деревья общих папок и другие объекты, специфичные для группы. На рисунке 12.3 показано, как это реализовано в компании Trains By Dave. Здесь понадобится создать группу администрирования для каждого из трех континентов, а также потребуется наличие группы администраторов Exchange, каждый из которых отвечает за поддержку серверов Exchange в своей географической зоне.
Если осуществляется переход с версии Exchange Server 5.5, и перед этим существовало несколько сайтов в организации Exchange 5.5, во время перехода придется использовать децентрализованную модель администрирования. Каждый сайт Exchange 5.5 будет создан как отдельная группа администрирования в Exchange Server 2003.
(рис 12.3) Децентрализованная модель администрированияЧтобы одновременно централизовать администрирование серверов Exchange 2003 и серверов Exchange 5.5, необходимо указать для административных групп полномочия доступа, ограничивающие администрирование групп только теми лицами, которые будут указаны. Это не приведет к включению серверов Exchange 5.5 в одну административную группу, но ограничит администрирование одной группой администраторов. Единственным способом реализации централизованной модели является миграция всех серверов Exchange 5.5 в систему Exchange Server 2003.
Примечание. Собственный режим означает, что в сети уже нет серверов Exchange более старых версий (т.е. на всех серверах функционирует система Exchange 2000 Server или Exchange Server 2003). Собственный режим для Exchange Server 2003 используется отдельно и отличается от собственного режима Microsoft Windows 2000 и более высоких функциональных уровней Windows Server 2003. Для получения подробной информации об этом режиме (что он означает и как действует в Exchange Server 2003) обратитесь к лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
Смешанная модель администрирования
Смешанная модель администрирования лучше всего подходит для того, чтобы ограничить выполнение определенных административных функций определенной группой людей, не создавая при этом специализаций для каждой административной функции. В данной модели создаются административные группы по функциям, а не по географическому местоположению или границам подразделений компаний. Например, можно создать группу администрирования, единственным дочерним объектом которой являются политики. В такой ситуации можно ограничить право создавать новые политики или изменять существующие политики для организации Exchange небольшой группой людей. Однако другие административные функции останутся под управлением принятой по умолчанию административной группы First Administrative Group (Первая группа администрирования), и они не будут включены в их собственную административную группу.
Данную модель можно также использовать для объединения специализированных административных функций и распределения по географическому принципу в одну административную модель. Например, создать одну административную группу для управления маршрутными группами, вторую группу – для управления политиками, третью группу – для подразделения Atlantic, четвертую группу – для отдела European и пятую группу – для управления всеми деревьями общих папок. На рисунке 12.4 показано, как это будет выглядеть для компании Trains By Dave, где сохранена децентрализованная модель для ежедневного администрирования, но используется централизованная модель, объединяющая деревья общих папок в одну административную группу и политики в другую административную группу.
(рис 12.4) Смешанная модель администрирования
Группы администрирования и полномочия доступа
Полномочия в Exchange Server 2003 базируются на модели полномочий доступа Active Directory. Это означает, что присвоение пользователю или группе полномочий доступа осуществляется по объекту, дочернему объекту или классу объектов.
Объект в Active Directory после создания наследует по умолчанию полномочия родительского объекта. Наследование позволяет распространять полномочия вниз по иерархии объектов, поэтому нет необходимости вручную присваивать дочернему объекту его полномочия. Кроме того, чтобы изменить полномочия для целого диапазона объектов, нужно всего лишь изменить эти полномочия для родительского объекта, а дочерние объекты автоматически унаследуют эти полномочия.
Модель присваивания полномочий доступа в Exchange Server 2003 обеспечивает контроль администраторов над распространением полномочий на контейнеры и объекты. Этот контроль осуществляется посредством специализированного наследования, которое позволяет указывать, что только определенные объекты наследуют полномочия. Вы можете задать наследование для следующих элементов:
только данный объект;
только наследник;
данный объект и вложенные контейнеры;
данный объект и дочерние объекты;
только вложенные контейнеры;
только дочерние объекты;
данный объект, вложенные контейнеры и дочерние объекты;
вложенные контейнеры и дочерние объекты.
Пример из практики.Как происходит распространение полномочий в разделе именования конфигурации
По умолчанию члены группы Enterprise Admins (Администраторы предприятия) имеют полный контроль над административными группами. Группа Domain Admins (Администраторы домена) тоже имеет существенные полномочия по этим объектам. На рисунке 12.5 показано окно консоли интерфейса служб Active Directory (ADSI Edit), из которого видно, как происходит наследование полномочий из контекста конфигурации (ADSI Edit – это оснастка MMC.)
Поскольку Exchange Server 2003 содержит значительную часть своей информации в разделе конфигурации Active Directory, организация Exchange создается именно в этом разделе. С точки зрения службы Active Directory, объект организации – это просто еще один объект, на который распространяются принятые по умолчанию полномочия доступа.
Если рассматриваемая среда устроена таким образом, что существует резкое отличие между деятельностью администраторов Exchange и администраторов доменов, то потребуется создать группу Exchange Admins (Администраторы Exchange) и предоставить этой группе полный контроль над всеми аспектами организации Exchange, а также ограничить глубину и объем полномочий для группы Domain Admins (Администраторы домена). Это необходимо сделать вручную в самом объекте-организации. Кроме того, потребуется блокировать наследование полномочий из раздела конфигурации Active Directory и переназначить полномочия на уровне организации для всех объектов Exchange Server.
(рис 12.5) Консоль ADSI Edit с отображением наследования полномочий для административных групп
Дополнительная информация. Подробнее о том, как блокировать наследование полномочий, рассказано в книге Microsoft Windows 2003 Security Administrator's Companion (автор Roberta Bragg, издательство Microsoft Press).
Создание группы администрирования
Поскольку Exchange Server 2003 устанавливается во многих компаниях небольшого и среднего масштаба, интерфейс Administrative and Routing Group (Группы администрирования и маршрутизации) отключен по умолчанию. Чтобы увидеть эти группы, перейдите в окно вкладки General (Общие) окна свойств организации (см. рис 12.6) и в области Administrative Views (Административные просмотры) включите опцию Display Routing Groups (Отображать маршрутные группы) и опцию Display Administrative Groups (Отображать административные группы), согласно надобности.
(рис 12.6) Включение интерфейса Administrative and Routing GroupПримечание. Хотя на рисунке 12.6 показан интерфейс в собственном режиме (native mode), эти конфигурации можно выбрать в смешанном режиме. Нет необходимости находиться в собственном режиме, чтобы отобразить группы маршрутизации и администрирования.
Следует отметить, что если сервер Exchange 2003 инсталлирован в существующем сайте Exchange 5.5, то интерфейс Administrative and Routing Group активизирован по умолчанию. Каждый сайт Exchange 5.5 отображается в оснастке Exchange System в виде отдельной административной группы. Для получения дополнительной информации о совместном использовании серверов Exchange 2003 и Exchange 5.5 обратитесь к лекции 3 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
После активизации интерфейса групп администрирования и маршрутизации можно начать установку административных групп. Для этого откройте оснастку Exchange System, щелкните правой кнопкой мыши на контейнере Administrative Groups (Группы администрирования), наведите указатель мыши на пункт New (Создать) и выберите пункт Administrative Group (Группа администрирования). На рисунке 12.7 показано окно свойств, в котором будет осуществляться работа. Введите имя создаваемой административной группы, введите нужные примечания в окне вкладки Details (Дополнительно), после чего будет создана группа администрирования.
(рис 12.7) Страница свойств новой группы администрированияПосле создания группы администрирования следует перейти к созданию дочерних объектов для этой группы. По умолчанию в группе не создается никаких объектов. Если щелкнуть правой кнопкой мыши на группе, появится контекстное меню, с помощью которого можно создать три новых контейнера:
контейнер Routing Groups (Маршрутные группы);
контейнер System Policy (Системная политика);
контейнер Public Folders (Общие папки).
Создание нового контейнера
Чтобы создать новый контейнер, который будет контролироваться данной группой администрирования, выберите нужный тип контейнера в контекстном меню (рис 12.8). После этого внутри данной группы будет создан соответствующий контейнер. При создании контейнеров на экране не появится какое-либо окно мастера. Также станет видно, что нет надобности в установке каких бы то ни было свойств, поскольку это просто контейнер. Этот объект можно рассматривать как блок, который содержит другие блоки, ни больше и не меньше. По мере создания групп маршрутизации для них будут указываться реальные свойства.
Примечание. На рисунке 12.8 показаны три опции для выбора, но иногда будут отображаться только две опции. Опция создания контейнера общих папок не появится на экране, если это новая группа администрирования, и внутри нее еще не создано других контейнеров. После создания нового контейнера, такого как Routing Groups, при создании второго контейнера будет видно, что в списке появилась опция Public Folders Container (Контейнер общих папок). Опция создания контейнера общих папок также не появится в списке, если уже создан контейнер этого типа, поскольку для каждой группы администрирования требуется только один контейнер общих папок.
(рис 12.8) Контекстное меню новой группы администрирования с отображением типов контейнеров, которые могут быть созданы
Объекты сервера и группы администрирования
В Exchange Server 2003 серверы всегда устанавливаются по умолчанию в группе First Administrative group внутри контейнера Server (Сервер). (First Administrative group [Первая группа администрирования] – это имя по умолчанию; его можно изменить в соответствии с соглашением об именовании групп администрирования. Для этого следует щелкнуть на имени правой кнопкой мыши.) Отметим, что нельзя создать контейнер серверов внутри новой группы администрирования и затем перемещать в нее серверы из группы First Administrative group. Эта особенность обусловлена структурой Exchange Server.
При создании новой группы администрирования автоматически создается контейнер Servers (Серверы) для этой группы, но он не отображается в оснастке Exchange System. Это видно на примере группы администрирования Hawaii. Если посмотреть на эту группу администрирования в окне оснастки Active Directory Sites and Services (Active Directory –сайты и службы), работающей в режиме Show Services (Отображение служб), то станет видно, что в группе Hawaii Admin group создан контейнер серверов (Servers) и контейнер Advanced Security (Дополнительная защита), несмотря на то что эти контейнеры не отображаются в окне оснастки Exchange System. Однако после установки сервера в группе администрирования этот объект-сервер появится в окне оснастки Exchange System. Поэтому необходимо создать группы администрирования до начала инсталляции серверов Exchange 2003, если планируется использовать эти серверы в нескольких группах администрирования.
(рис 12.9) Объект сервера группы администрирования Hawaii Admin group в окне оснастки Active Directory Sites and Services
Политики Exchange 2003
Политики в Exchange Server 2003 предназначены для повышения гибкости администрирования при одновременном снижении нагрузки на администраторов. Политика – это набор параметров конфигурирования, которые применяются к одному или нескольким объектам одного класса в Exchange. Например, можно создать политику, которая воздействует на определенные параметры некоторых или всех серверов Exchange. Если потребуется изменить эти параметры, то достаточно модифицировать эту политику, и она будет применена к соответствующей организации сервера.
Существует два вида политик: системная политика (system policy) и политика получателей (recipient policy). Политики получателей применяются к объектам с доступом к почте и указывают, каким образом генерируются адреса электронной почты. Речь о политиках получателей идет в ).
(рис 12.10) Объект "системная политика"Примечание. При установке Exchange Server 2003 не создается контейнер по умолчанию для системных политик. Его необходимо создать перед построением системных политик. Щелкните правой кнопкой мыши на группе администрирования, в которой требуется создать папку политики, наведите указатель мыши на пункт New (Создать) и выберите System Policy Container (Контейнер системной политики).
Создание системной политики
Для создания системной политики нужно перейти в соответствующий контейнер System Policies (Системные политики), щелкнуть правой кнопкой мыши на контейнере, после чего выбрать тип создаваемой политики: политика сервера, политика хранилища почтовых ящиков или политика хранилища общих папок.
При работе с системными политиками не забудьте создать объектполитику в группе, которая несет ответственность за администрирование этой политики. Иначе может произойти ошибка в выборе людей, которые осуществляют административный контроль за критически важными политиками. Рассмотрим, как создается каждый из трех типов политик, начиная с политик серверов.
Создание политики серверов
Политика серверов определяет параметры отслеживания сообщений и обслуживания файлов журналов. Она не применяется к параметрам безопасности или другим параметрам серверов в данной группе администрирования. Чтобы создать политику серверов, щелкните правой кнопкой мыши на контейнере System Policies (Системные политики), укажите на пункт New (Создать) и затем выберите вариант Server Policy (Политика серверов). Появится диалоговое окно New Policy (Создание политики), показанное на рис 12.11, в котором указываются вкладки, отображаемые на странице свойств данной политики. Для политики серверов имеется только одна опция: вкладка General (Общие). Отметьте опцию для этой вкладки и затем нажмите OK. Отобразится окно конфигурирования, в котором будет создана данная политика.
(рис 12.11) Диалоговое окно New Policy (Создание политики)После этого нужно ввести имя политики в окне вкладки General страницы свойств данной политики. Как показано на рисунке 12.12, на самом деле существует две вкладки General. Первая вкладка используется для ввода имени политики. Выберите имя для описания задачи, для выполнения которой предназначена данная политика, например Message Tracking Policy (Политика отслеживания сообщений) или Enable Subject Logging Policy (Политика "Активизировать регистрацию тем сообщений"). Подходящее имя, выбранное на этой стадии, сэкономит время работы, так как не будет необходимости открывать страницу свойств этой политики, чтобы определить ее назначение.
Вкладка General (Policy) (Общие [Политика]), показанная на рис 12.13, содержит реальные параметры политики, применяемые к серверам Exchange рассматриваемой организации. Вкладка называется General (Policy), так как потенциально осуществляется конфигурация вкладки General страниц свойств для всех имеющихся серверов. (Ниже в этой лекции мы рассмотрим, как применять эту политику ко всем серверам организации.) Если сравнить эту вкладку с вкладкой General на странице свойств какого-либо сервера, то станет видно, что эти вкладки совпадают, за исключением идентифицирующей информации вверху вкладки.
На вкладке General (Policy) активизируется регистрация и отображение на экране тем сообщений (Enable subject logging and display) для всех имеющихся серверов Exchange 2003. Эта установка действует в сочетании с опцией Enable Message Tracking (Активизировать отслеживание сообщений), что позволяет отслеживать сообщения, передаваемые в организации. Эти опции полезны для поиска и устранения источника проблем, возникающих, когда некоторые пользователи не получают сообщений от других пользователей. Существует возможность отслеживания прохождения сообщения через организацию для определения места, в котором имеются проблемы с передачей данных. Подробнее об отслеживании сообщений и регистрации тем сообщений рассказывается в лекции 6 "Функциональность, безопасность и поддержка Exchange Server 2003".
(рис 12.13) Ввод имени политики в окне вкладки General(рис 12.12) Вкладка General (Policy)После того как политика начала действовать, ее нельзя изменить на уровне локальных серверов. Политика отслеживания сообщений, которую мы использовали в качестве примера, была сформирована на сервере EX-SRV1 в группе администрирования Arizona. На рисунке 12.14 показано, что параметры отслеживания сообщений недоступны для изменения на странице свойств сервера EX-SRV1, поскольку эти значения определены политикой.
(рис 12.14) Окно свойств сервера EX-SRV1 с недоступными (затененными) параметрами отслеживания сообщений (Message tracking)На данном этапе, скорее всего, вы хотели бы узнать, как мы применили политику к этим трем серверам. Чтобы применить политику после ее создания, выполните следующие шаги. Щелкните правой кнопкой мыши на новой политике, после чего выберите Add Server (Добавить сервер). Появится диалоговое окно, позволяющее указать комбинацию серверов в организации Exchange. После создания политики ее можно применить к любой комбинации серверов в рассматриваемой организации Exchange. После выбора серверов нажмите OK, и политика будет применена к указанным серверам. Чтобы проверить это, выделите созданный объект-политику в окне оснастки Exchange System. Добавленные серверы отобразятся справа в окне детализованной информации (см. рис 12.15).
Чтобы удалить сервер из списка политики, перейдите в объект-политику данного сервера в окне оснастки Exchange System. В окне детализированной информации выделите сервер, который требуется удалить. Щелкните правой кнопкой мыши на этом сервере и выберите пункт Remove From Policy (Удалить из политики).
(рис 12.15) Серверы, к которым применяется выбранная политикаЕсли в существующую политику вносятся изменения после того, как были сохранены прежние изменения, на экране появится окно с предложением немедленно применить изменения в политике ко всем объектам. На выбор предлагаются опции Yes (Да) или No (Нет). Выбор Yes означает, что данная политика будет немедленно применена к соответствующим объектам. Ответ No, означает, что изменения политики будут применяться через обычные периоды репликации.
Создание политики хранилищ общих папок
Политики хранилищ общих папок определяют ряд параметров конфигурации, включая расписания технического обслуживания, пределы хранения элементов и индексирование по всему тексту. Они применяются к каждому хранилищу в границах дерева общих папок.
Процедура создания политик хранилищ общих папок аналогична процедуре создания политики серверов, описанной в предыдущем разделе. Однако здесь есть возможность указать пять вкладок для страницы свойств политики хранилищ общих папок.
General (Policy) (Общие [Политика]). Здесь активизируется поддержка стандарта S/MIME (Secure/Multipurpose Internet Mail Extensions – защищенные/многоцелевые почтовые расширения интернета) и указывается необходимость преобразования текста в формат шрифта с фиксированным размером (10-точечный Courier).
Database (База данных). На данной вкладке указывается, нужно ли выполнять ежедневное техническое обслуживание общих папок.
Replication (Репликация). Определяет, насколько часто должна происходить репликация общих папок, а также предельный размер репликации и интервал репликации (в минутах) при использовании опции Always (Всегда).
Full-Text Indexing (Индексирование по всему тексту). Определяет интервал модификации и интервал полного обновления индекса для общих папок.
)
Более подробно о параметрах хранилища общих папок рассказывается в лекции 10.
(рис 12.16) Вкладка Limits (Policy) страницы свойств для политики хранилищ общих папокЧтобы применить политику к общим папкам, ее нужно связать с ними точно так же, как это было сделано с политикой серверов в предыдущем разделе. По умолчанию никакая политика не применяется к предполагаемому объекту этой политики; необходимо связать (ассоциировать) ее с этим объектом, выбрав пункт Add Public Store (Добавить общее хранилище) в контекстном меню данной политики.
В отличие от политики серверов, которые содержат только одну вкладку на своих страницах свойств, политика хранилищ общих папок содержит до семи вкладок. Это не означает, что необходимо использовать все эти вкладки. Если требуется добавить или удалить вкладки в существующей политике хранилищ общих папок, то для этого достаточно щелкнуть правой кнопкой мыши на политике и выбрать пункт Change Property Pages (Изменить страницы свойств). Затем следует выбрать вкладки, которые нужно добавить или удалить, и сконфигурировать их нужным образом.
Создание политики хранилищ почтовых ящиков
Политика хранилищ почтовых ящиков позволяет настраивать ряд параметров для почтовых ящиков, включая принятое по умолчанию хранилище почтовых ящиков, график технического обслуживания, получателя, который ведет журнал сообщений (то есть получает копии всех сообщений электронной почты, проходящих через организацию), и индексирование по всему тексту. При создании политики хранилищ почтовых ящиков в страницу свойств этой политики включаются вкладки General (Общие), Database (База данных), Limits (Пределы хранения) и Full-Text Indexing (Индексирование по всему тексту).
Примечание. Ведение журнала сообщений (message journaling) – это концепция, которая введена в пакете обновления Service Pack 1 для Exchange 5.5. По существу это отправка копий большинства сообщений электронной почты общему получателю для последующего использования в юридических или государственных целях. Это средство чаще всего активизируется в тех случаях, когда компания вынуждена сохранять все свои сообщения электронной почты в соответствии с государственными правилами или в юридических целях.
На вкладке General (Policy) указывается используемое по умолчанию хранилище общих папок для хранилищ почтовых ящиков, которые будут связаны (ассоциированы) с этой политикой. Это очень удобно, если требуется создать большое число хранилищ общих папок и ассоциировать большинство (или все) хранилищ с определенным хранилищем общих папок. На вкладке General (Policy) также указывается используемый по умолчанию автономный список адресов (Default offline address list), который будет применяться в выбранных хранилищах почтовых ящиков. Также существует возможность указать архивирование сообщений в этом хранилище. Кроме того, можно активизировать клиентскую поддержку электронных подписей в стандарте S/MIME, а также включить использование шрифта с фиксированным размером для всех поступающих сообщений.
Единственный элемент, указываемый на вкладке Database (Policy), – время ежедневного технического обслуживания. Если также создается политика хранилищ общих папок, то необходимо предусмотреть, чтобы у этих политик время технического обслуживания различалось, чтобы повысить производительность системы при выполнении процедуры оперативного технического обслуживания. Планируя свою работу, предусмотрите дополнительные процедуры, которые будут выполняться во время простоя, включая программы резервного копирования, дефрагментацию базы данных и репликацию.
Примечание. К основным действиям, выполняемым с хранилищем в целях технического обслуживания, относятся: проверка существования нужных папок Free/Busy и папок автономных адресных книг для группы администрирования и, если эти папки не существуют, их создание; стирание индексов базы данных, которые были созданы раньше, но в последнее время не используются; стирание тех элементов, у которых истекло время хранения удаленных элементов (это называется окончательным удалением); удаление элементов общих папок, у которых истек срок старения; стирание удаленных из хранилища почтовых ящиков, у которых превышен окончательный срок хранения; выявление почтовых ящиков, не связанных с каким-либо объектом-пользователем, а также выявление почтовых ящиков, которые повторно связаны с каким-либо пользователем.
На вкладке Limits (Policy), показанной на рис 12.17, устанавливаются пределы хранения и параметры удаления. Определяя предельный размер почтового ящика, можно включать уведомление службой System Attendant пользователей о том, что они превысили этот предел. Используйте кнопку Customize (Настроить), чтобы создать специализированный график, позволяющий устанавливать несколько моментов времени в течение суток, когда пользователи, превысившие предельные размеры своих почтовых ящиков, будут получать уведомления о том, что они должны предпринять какие-то действия для уменьшения размера своих почтовых ящиков.
(рис 12.17) Вкладка Limits (Policy) страницы свойств политики хранилищ почтовых ящиковПолитика хранилищ почтовых ящиков применяется на уровне хранилищ, но не на уровне групп хранения или серверов. Кроме того, необязательно монтировать хранилище так, чтобы его можно было ассоциировать с определенной политикой. Более подробно о параметрах хранилища почтовых ящиков рассказывается в лекции 11.
Разрешение конфликтов политик
Когда две различные политики применяются к одному объекту, возможен конфликт между этими политиками. В этом случае принято по умолчанию, что более поздняя политика замещает более раннюю политику. Но при включенной опции Do Not Allow The Removal Of This Policy From The Items It Applies To (Не разрешается удалять эту политику из элементов, к которым она применяется) более поздняя политика не сможет заменить более раннюю, и отобразится сообщение о том, что данный объект находится под контролем конфликтующей политики. Далее появится запрос о выводе данного объекта из-под контроля конфликтующих политик. Если выбрать Yes (Да), то будет применена новая политика, а если выбрать No (Нет), то будет сохранена старая политика.
Создание и администрирование групп маршрутизации
Как мы уже говорили, группа администрирования – это набор объектов, которые сгруппированы таким образом, чтобы осуществлять объединенное администрирование этих объектов. В отличие от нее группа маршрутизации – это набор серверов, между которыми обеспечивается постоянное соединение с высокой пропускной способностью. Предполагается, что каналы между группами маршрутизации являются медленными или ненадежными. Для соединения групп маршрутизации через эти медленные каналы глобальной сети используются коннекторы. Таким образом, группы администрирования являются логическими по своей природе, в то время как группы маршрутизации определяются физической топологией сети.
Группы маршрутизации позволяют указывать маршруты, по которым будут проходить сообщения от отправителя к получателю внутри организации. Используя значения стоимостей, применяемые на коннекторах, можно задавать преимущественный физический маршрут прохождения сообщений в организации. Подробнее об архитектуре групп маршрутизации рассказывается в лекции 3.
Создание группы маршрутизации
Создание групп потребуется в том случае, если имеется два или больше серверов, соединенных медленным или ненадежным каналом глобальной сети. Группы маршрутизации создаются в смешанном или в собственном режиме. Границы групп маршрутизации необязательно должны соответствовать границам групп администрирования в собственном режиме, но в смешанном режиме они не могут охватывать несколько административных групп. Это ограничение обуславливается способом взаимодействия Exchange 5.5 с Exchange Server 2003. Пока Exchange Server 2003 находится в смешанном режиме, он сохраняет способность взаимодействия с Exchange 5.5. А поскольку в Exchange 5.5 нельзя перемещать серверы между сайтами, то не существует возможности перемещать их между группами маршрутизации или администрирования в Exchange Server в смешанном режиме.
Группы маршрутизации создаются внутри контейнера Routing Groups (Группы маршрутизации). Если конкретная ситуация позволяет сделать это, то новые контейнеры Routing Groups могут создаваться в других группах администрирования. В каждой группе администрирования может быть создан только один контейнер Routing Groups, но в каждом контейнере Routing Groups можно создать несколько групп маршрутизации.
Чтобы создать группу маршрутизации, щелкните правой кнопкой мыши на контейнере Routing Groups, укажите на пункт New (Создать) и затем выберите опцию Routing Group (Группа маршрутизации). Введите имя новой группы маршрутизации на вкладке General и нажмите OK.
Новая группа маршрутизации состоит из двух дочерних объектов – Connectors (Коннекторы) и Members (Члены) (см. рис 12.18). В контейнере Connectors будут создаваться коннекторы Routing Group Connectors (подробнее об этом рассказывается в лекции 13), а в контейнере Members будут размещаться объекты-серверы, являющиеся членами группы маршрутизации.
Если необходимо подсоединиться к внешней системе электронной почты, то это можно сделать путем установки коннектора X.400 Connector или SMTP Connector (как правило, первого из них). (О том, как подсоединиться к внешней системе, рассказывается в лекции 1 "Функциональность, безопасность и поддержка Exchange Server 2003"). Эти коннекторы также используются для соединения групп маршрутизации внутри рассматриваемой организации, но лучше взять для этой цели Routing Group Connector (Коннектор групп маршрутизации). RGC можно использовать только внутри организации для соединения групп маршрутизации. Его нельзя использовать для соединения с внешней системой электронной почты.
Управление группой маршрутизации
Две из наиболее важных задач в администрировании маршрутной группы – это создание новых групп маршрутизации и добавление одного или нескольких серверов к группе маршрутизации. Добавляя сервер к группе маршрутизации, системе Exchange Server 2003 фактически сообщается о том, что добавляемый сервер имеет постоянную возможность соединения с другими серверами данной группы с высокой пропускной способностью. Несмотря на то что не существует минимального предела пропускной способности, жестко установленного в операционной системе Exchange, рекомендуется абсолютный минимум 64 Кбит/с при постоянной возможности соединения.
(рис 12.18) Объекты в новой группе маршрутизацииПримечание. Не забудьте проверить имеющиеся каналы глобальной сети (WAN), прежде чем начать реализацию Exchange Server 2003. Выделенная линия со скоростью 64 Кбит/с, возможно, обеспечивает более постоянную пропускную способность, чем линия T1, которая часто насыщена трафиком, не относящимся к Exchange. Имеет смысл принять в расчет другие виды трафика по каналам глобальной сети и затем использовать остающуюся часть пропускной способности, чтобы оценить, хватает ли этого для обеспечения постоянного соединения с высокой пропускной способностью.
Чтобы добавить сервер к группе маршрутизации, найдите и выделите контейнер Members группы маршрутизации, которой принадлежит в данный момент этот сервер (по умолчанию это First Routing Group). Перетащите этот сервер в контейнер Members нужной группы маршрутизации.
Примечание. При перемещении сервера из какой-либо группы маршрутизации фактически происходит перемещение виртуального сервера SMTP или службы X.400, с помощью которой этот сервер осуществляет взаимодействие, причем эта служба повторно создается в новой группе маршрутизации.
По умолчанию все серверы, созданные в новой организации, принадлежат группе First Routing Group (Первая группа маршрутизации), используемой по умолчанию, которая создается при первоначальной инсталляции Exchange Server 2003. Однако вполне возможно, что потребуются дополнительные группы маршрутизации, согласно физической топологии сети.
Чтобы переименовать объект "группа маршрутизации", щелкните правой кнопкой мыши на данной группе маршрутизации, выберите пункт Rename (Переименовать) и введите новое имя. Чтобы удалить группу маршрутизации, необходимо сначала переместить в другие группы маршрутизации все серверы, которые входят в удаляемую группу маршрутизации. Нельзя удалить группу маршрутизации, в которой находятся объекты-серверы, включенные в контейнер Members. Переместив все серверы, щелкните правой кнопкой мыши на данной группе маршрутизации и выберите пункт Delete (Удалить). Нажмите Yes (Да), чтобы подтвердить удаление группы маршрутизации.
Заключение
В данной лекции рассказывалось о том, как создавать и осуществлять управление группами администрирования и маршрутизации. Когда речь идет о группах маршрутизации, контейнеры сами по себе не представляют сложности в управлении. Тем не менее, не всегда легко создавать коннекторы между группами маршрутизации и осуществлять управление ими, и данная задача нередко усложняет работу администратора. В следующей лекции мы уделим внимание вопросам, связанным с коннекторами групп маршрутизации.
