Переход с zimbra на exchange: Установка обновлений на Exchange Server 2013/2016 в DAG

Установка обновлений на Exchange Server 2013/2016 в DAG

Выпущены долгожданные обновления для почтовых серверов Exchange. Обновления весьма существенные, поэтому настоятельно советую ознакомиться с перечнем изменений. Команда Exchange отказалась от сервис паков и сейчас концепция такова, что накопительные обновления выходят каждый квартал и могут содержать в себе как исправления багов, дыр в безопасности,  так и новый функционал продукта. Но сегодня я хотел бы поговорить не об этом, а о процедуре установки обновлений на серверах Exchange Server 2013/2016.

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

• Не рекомендуется устанавливать обновления сразу в рабочей среде. Необходимо иметь стенд, для тестирования вашей конфигурации.

• Не рекомендуется настраивать почтовый сервер на автоматическую установку обновлений получаемых от WSUS или из внешнего источника. Это справедливо как для Exchange Server, так и для Windows Server.

• Если у вас развёрнут Exchange Server 2013, а его роли CAS и MBX разнесены по разным серверам, то первым должен обновляться CAS сервер.

• При обновлении CAS сервера советую вывести его из балансировки подключений (если она есть).

• При обновлении CAS сервера все ваши персональные настройки веб сервера IIS сбросятся на дефолтные, так что нужно сделать бэкап.

• При обновления почтовых серверов, находящихся в DAG, обновляемый сервер необходимо вывести в режим обслуживания.

• Если у вас единственный сервер Exchange в организации, то желаю вам удачи и не забудьте сделать бэкап :). При обновлении почтовый сервер будет недоступен для пользователей.

Итак, перейдем непосредственно к самой процедуре обновления. Качаем дистрибутив с CU (отмечу, что это полноценный дистрибутив Exchange и если вы устанавливаете новый сервер, сразу качайте CU) и распаковываем его в папку C:\tmp. В случае с Exchange Server 2016 это будет ISO-образ а не архив [ура товарищи!]. ISO-образ нужно подмонтировать, открыть и так же распаковать.

Мы рассмотрим установку обновлений на сервере почтовых ящиков, входящим в DAG. Открываем любимый инструмент администратора Exchange PowerShell (с повышенными привилегиями) и приступаем к работе.

Переводим компонент сервера Hub Transport в режим обслуживания:

Set-ServerComponentState EX-SRV –Component HubTransport –State Draining –Requester Maintenance

Переводим все активные сообщения из очередей почтового сервера на другой сервер (нужно указать FQDN севера):

Redirect-Message -Server EX-SRV -Target EX2-SRV.contoso.com

(подтверждаем действие нажав “y”)

Приостанавливаем членство в кластере:

Suspend-ClusterNode –Name EX-SRV

Следующая команда перемещает все активные копии баз данных с сервера EX-SRV и блокирует политику активацию новых копий:

Set-MailboxServer EX-SRV –DatabaseCopyActivationDisabledAndMoveNow $true

Переводим сервер в режим обслуживания:

Set-ServerComponentState EX-SRV -Component ServerWideOffline –State InActive –Requester Maintenance

Теперь перейдем в директорию с распакованным обновлением (CU) и расширим схему AD (нужен компонент Windows Server «RSAT-ADDS» и обновление безопасности) будем использовать для этого cdm. exe запущенную от Администратора:

setup.exe /prepareschema /IAcceptExchangeServerLicenseTerms

Подготовим Active Directory:

setup.exe /preparead /IAcceptExchangeServerLicenseTerms

Подготовим домен (запускается для каждого домена, содержащего почтовый сервер Exchange):

setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

Начнем установку обновления:

setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms

После установки возвращаем все в рабочее состояние:

Resume-ClusterNode –Name EX-SRV
Set-MailboxServer EX-SRV –DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer EX-SRV –DatabaseCopyActivationDisabledAndMoveNow $false
Set-ServerComponentState EX-SRV –Component HubTransport –State Active –Requester Maintenance

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

Раскидываем базы данных, согласно приоритету активации, для этого переходим в папку C:\Program Files\Microsoft\Exchange Server\V15\scripts и выполняем команду:

.\RedistributeActiveDatabases.ps1 –DagName DAGNAME –BalanceDbsByActivationPreference –confirm: $false 

Готово. Проверяем репликацию:

Test-ReplicationHealth -Identity EX-SRV 

Осталось убедиться в отсутствии проблем у пользователей и сторонних сервисов и можно приступать к обновлению следующего сервера.

Полезные ссылки:

О содержании обновлений и вносимых изменениях см. Блог команды Exchange 

Скрипты для автоматического перевода сервера в режим обслуживания и обратно:

Exchange Server 2013 Maintenance Mode Script (Start)

Exchange Server 2013 Maintenance Mode Script (Stop)

Поделиться ссылкой на эту запись:

Похожее

Zimbra Collaboration Server. Альтернатива Microsoft Exchange – недорогая и удобная::Журнал СА 10.2011

 ОКСАНА КУРЫШЕВА, консультант НЦПР

Zimbra Collaboration Server^*
Альтернатива Microsoft Exchange – недорогая и удобная

Проблемы перехода

Проблем у организации, «подсевшей» на сервисы компании Microsoft, две:

• Невозможность сменить часть приложений на аналогичные от другого поставщика. Все приложения Microsoft полноценно работают в рамках единой большой системы, и убрать, например, SharePoint, оставив Exchange, кажется невозможным.
• Сложность использования сервисов Microsoft пользователями не Windows-систем. Будь то MacOS или Linux, полноценных клиентов (MS Office, Outlook) для этих операционных систем нет.

Если учесть обе эти проблемы, мигрировать на другую платформу кажется нереальным. У организаций, в которых все ПО работает на Microsoft, часто нет возможности аккуратно и постепенно мигрировать всю инфраструктуру на Linux.

Как справиться с задачей?

Как правило, решение такой проблемы для каждой организации является уникальным. В качестве примера миграции рассмотрим возможность перехода с Exchange + Outlook на СПО для пользователей из Microsoft Active Directory.

Требования к новой системе

• Наличие полноценного почтового клиента для Windows, Linux, MacOS.
• Возможность сосуществования с MS Exchange на время миграции.
• Интеграция с Active Directory.
• Выполнение всех основных функций MS Exchange (почта, календари, задачи, документы из SharePoint).

Выбор решения

Среди альтернатив MS Exchange есть немало открытых решений, но все они удовлетворяют только некоторым из требований. Из хорошо подходящих вариантов можно предложить две альтернативы: Zimbra и Zarafa. Рассмотрим соответствие системы Zimbra требованиям и возможности миграции на нее. Zimbra Collaboration Server обеспечивает более дешевую альтернативу Microsoft Exchange, встраивается в инфраструктуру на базе Microsoft, при этом может минимально влиять на работу пользователей.

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

Кроме того, для Zimbra существует кроссплатформенный клиент совместной работы Zimbra Desktop, способный заменить Outlook и при этом работающий на Windows, Linux и MacOS.

Рисунок 1. Поддержка разных платформ

Материалы по возможностям системы Zimbra Collaboration Server и миграции на Zimbra с Microsoft Exchange можно найти на:

* На правах рекламы

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

Перенос почтового сервера на Zimbra Collaboration Suite

Пришло время перенести почту со старого почтового сервера (Postfix + Courier-Imap + SASL2 + MySQL + ClamAV) на новый сервер Zimbra Collaboration Suite. Причем сделать это нужно максимально незаметно для пользователей.

Поскольку на нашем сервере порядка 300 активных ящиков все сразу перенести невозможно, поэтому делать придётся постепенно.

Идея такая: создали ящик на новом сервере — перенастроили пользователю почтовый клиент (при этом названия ящика должно сохраниться) — перешли к следующему.

Вот что мы имеем:

• mail.example.com — существующий почтовый сервер с ip:62.220.58.71, обслуживаемый зону example.com
• zcs.example.com — новый почтовый сервер на zimbra с ip:62.220.58.72, обслуживаемый зону example.com

Меняем транспортные карты

Сначала нужно сделать так, чтобы сервер zcs.example.com принимал почту для пользователя [email protected], а всю остальную почту для домена example.com отправлял на сервер mail.example.com.

Старый сервер mail.example.com наоборот всю почту адресованную домену example. com обслуживал сам, а почту для [email protected] пересылать на сервер zcs.example.com.

На новом сервере Zimbra

Zimbra хранит транспортные карты в LDAP:

# su - zimbra -c "zmprov gacf | grep zimbraMtaTransportMaps"

zimbraMtaTransportMaps: proxy:ldap:/opt/zimbra/conf/ldap-transport.cf

Создадим файл /opt/zimbra/conf/transport.cf:

# mcedit /opt/zimbra/conf/transport.cf

example.com             smtp:[172.16.0.1]
[email protected]       local:[172.16.0.2]

# /opt/zimbra/common/sbin/postmap /opt/zimbra/conf/transport.cf

Заставим Zimbra использовать данный файл в качестве транспорта:

# su - zimbra
$ zmprov mcf zimbraMtaTransportMaps "proxy:ldap:/opt/zimbra/conf/ldap-transport.cf, lmdb:/opt/zimbra/conf/transport.cf"
$ zmmtactl reload


На старом сервере Postfix

Посмотрим, что использует старый сервер mail. example.com в качестве транспорта:

# postconf transport_maps

transport_maps = hash:/etc/postfix/transport.cf

Правим файл /etc/postfix/transport.cf:

# mcedit /etc/postfix/transport.cf

[email protected]         smtp:[172.16.0.2]

# postmap /etc/postfix/transport.cf

Готово. Теперь неважно, какой из серверов получит почту для ящика [email protected] она в любом случае придет на новый сервер zcs.example.com и будет храниться там.

Не забывайте после каждого изменения файла transport.cf применять команду postmap.

Правим DNS-зону

Если ваш новый сервер имеет свой внешний ip-адрес, то необходимо добавить в dns-зону example.com mx-запись нового сервера и отредактировать spf:

$ORIGIN .
$TTL 3600
example.com IN SOA example.com. hostmaster.example.com. (
2017011001 ; serial
3600 ; refresh [1h]
600; retry [10m]
1209600 ; expire [14d]
3600 ; min TTL [1h]
)
NS mail. example.com.
MX 10 mail.example.com.
MX 20 zcs.example.com.
A 62.220.58.71
IN TXT "v=spf1 a ip4:62.220.58.71 ip4:62.220.58.72 ~all"

$ORIGIN example.com.
mail IN A 62.220.58.71
zcs IN A 62.220.58.72

Результат

Таким образом, постепенно обойдя пользователей, мы перенесли почту на новый сервер.
После того как все пользователи перенесены со старого сервера убираем информацию о нем в DNS-зоне, настраиваем DKIM и
серые списки (при помощи плагина Policyd).

Настройка переадресации в Zimbra | Настройка серверов windows и linux

Добрый день уважаемые читатели и гости блога pyatilistnik.org, сегодня мне хочется вам показать, каким образом вы можете настроить переадресацию на почтовом ящике Zimbra. Приведу пример использования данного действия, вы уходите в отпуск или у вас увольняется сотрудник и вы хотели бы его входящую почту перенаправить на другой электронный ящик сотрудника. Делается это для того, чтобы не оповещать клиентов о смене ящика, так как бизнес процесс уже построен.

Фильтры в Zimbra

С фильтрами, я вас уже знакомил, когда мы решали проблему со входящими письмами. Что такое фильтры — это механизм почтового сервера Zimbra, который позволяет определить правила управления для всей почты (Входящей или исходящей), в их задачи входит автоматическое распределение сообщений, по заранее настроенным правилам.

Переходим ваш почтовый ящик Zimbra. В самом верху, у вас будет вкладка «Настройки», далее выбираете пункт «Фильтры»

Для создания переадресации почты, вам необходимо создать новый фильтр. Нажимаем соответствующую кнопку. У фильтра вы обнаружите вот такие параметры:

• Название
• Соответствие условию — по сути это условие, на основании которого будет выполняться фильтрация писем.
• Выполнить следующие действия — тут все понятно без описание, куда все завернуть.

Задаем для перенаправления писем условие. Название фильтра «Пересылка», в соответствиях выбираем, «Кому» «Содержит» «Значок @» (@ означает все письма, если нужно только конкретные то укажите адрес или домен). В действиях выберите «Перенаправить на адрес» и укажите нужный почтовый ящик.

Например, можно задать правило фильтра для выявления почтовых сообщений от непосредственного руководителя и перемещения их в папку под названием «От моего шефа» или для автоматического перемещения сообщений с определенного адреса в Корзину.

Фильтрация исходящих сообщений выполняется со следующими целями.

• Сортировка сообщений, сохраненных в папке «Отправленные», по другим папкам.
• Автоматическое присвоение тегов сообщениям.
• Пересылка сообщений.
• Пометка сообщений как прочитанных или флагом.
• Отклонение сообщений.

Условия фильтра

Каждый фильтр — это правило с одним или несколькими условиями и целью. Каждое правило фильтра может содержать несколько условий. Например, если ваш руководитель отправляет вам почту с нескольких адресов, например [email protected] или [email protected], можно создать один фильтр с названием «Руководитель», который будет содержать два условия — по одному для каждого электронного адреса.

Условия включают:

• Определенные адреса в полях «От», «Кому» и «Копия» в заголовке сообщения электронной почты
• слова или строки знаков в теме или теле письма;
• наличие или отсутствие вложений;

все условия можно указать как отрицательные, добавив префикс «не». Например, можно указать сообщение, которое не содержит конкретного слова.

Можно объединить условия для поиска сообщений с более сложными характеристиками.

Параметры «Любое» и «Все»

Условия правила фильтра можно сгруппировать по принципу любое или все. Эти условия используются аналогично условиям поиска «AND» и «OR», описанным в разделе описания функции «Поиск», где условие любое используется как OR, а все — как AND.

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

Действия правила фильтра

В каждом правиле фильтра может быть определено одно или несколько действий, Действия могут быть следующими.

• Оставить сообщение в папке «Входящие» (действие не выполняется).
• Переместить сообщение в указанную папку.
• Пометить сообщение тегом.
• Пометить сообщение как прочитанное или флагом.
• Отклонить сообщение. В результате этого действия сообщение «молча» отклоняется. Это действие не аналогично действию «Удалить». В результате удаления элемент перемещается в Корзину. В результате отклонения сообщение даже не дойдет до почтового ящика.
• Переслать сообщение на другой адрес.

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

Когда применяются фильтры

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

Правила фильтра можно также применить к существующему набору почтовых элементов. В настройках почтовых фильтров есть кнопка Запустить фильтр, с помощью которой можно выбрать несколько фильтров и применить их к указанным папкам почты.

Порядок фильтрации

Фильтры применяются в том порядке, в котором они перечислены в настройках почтовых фильтров. Порядок можно изменить.

Условия каждого фильтра используются для проверки каждого сообщения. Если сообщение соответствует всем условиям (любому или всем, в зависимости от того, как определено в правиле фильтра), тогда оно считается соответствующим заданному критерию. Порядок условий в каждом фильтре не имеет значения.

Если сообщение соответствует условиям, к нему применяются все действия, связанные с этим фильтром, в том порядке, в каком они установлены в фильтре.

Базовая настройка Exchange Server 2019. Часть 1

Базовая настройка Exchange Server является обязательной задачей после установки продукта. О том как выполнить установку, какие необходимо учесть нюансы можно ознакомится по следующей ссылке.
Весь процесс базовой настройки разбит по кейсам, итог выполнения которых — работоспособный Exchange сервер. Будут реализованы возможности отправки и получения электронной почты, а также выполнены условия для подключения клиентов. Виду объема необходимой конфигурации, весь материал разбит на две статьи. В первой части рассматриваются следующие вопросы:

• Добавление обслуживаемого домена (accepted domains)
• Настройка соединителя отправки (send connector)
• Настройка внешних URL адресов Exchange сервера

Во второй:

• Выпуск SSL сертификатов для Exchange сервера
• Настройка политики адресов электронной почты

Добавление обслуживаемого домена (accepted domains)

Обслуживаемый домен (accepted domains) — это домен, который используется Exchange организацией для получения и отправки почтового трафика. В рамках него (типы Authoritative и Internal Relay) могут формироваться почтовые адреса пользователей, общих почтовых ящиков, групп распространения и других объектов Exchange которым возможно назначить почтовый адрес.
По умолчанию, сразу же после развертывания, доступен лишь один обслуживаемый домен:

Обслуживаемые домены (accepted domains) Exchange

Имя его соответствует домену Active Directory. Всего существует три типа обслуживаемых доменов:

1. Уполномоченный домен (Authoritative)
2. Домен внутренней ретрансляции (Internal Relay)
3. Внешний домен ретрансляции (External Relay)

Домены первого типа полностью обслуживаются Exchange организацией. При поступлении на него входящего письма происходит поиск почтового адреса в глобальном каталоге Active Directory. В случае его отсутствия будет возвращен NDR (Not Delivery Report).

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

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

Если письмо будет доставляться в Exchange организацию, а домен получателя отсутствует в обслуживаемых доменах, оно автоматически будет отклонено с ошибкой 550 5.7.54 SMTP; Unable to relay recipient in non—accepted domain.

Сам процесс добавления домена необходимого типа выглядит следующим образом:

Добавление обслуживаемого домена в Exchange

Настройка соединителя отправки (send connector)

В Exchange инфраструктуре коннекторы или соединители выполняют задачи обработки входящего и исходящего почтового потока, также участвуют внутри транспортного потока Exchange. Чтобы почтовая инфраструктура могла взаимодействовать с внешними системами по протоколу SMTP, необходимо создать новый соединитель отправки. Для этого следует перейти в раздел почтовый поток (mail flow), во вкладку исходящие почтовые соединители (send connectors)

Исходящие почтовые соединители Exchange

Как и в случае с обслуживаемыми доменами, существует несколько типов исходящих почтовых соединителей:

• Внутренний (Internal)
• Внешний (Internet)
• Партнерский (Partner)

Создание нового почтового соенденителя в Exchange

Внутренний соединитель отправки используется для ретрансляции почтового потока внутри почтовой организации. Например, в сочетании с доменом внутренней ретрансляции.

Внешний тип предполагает отправку почты во вне организации, например удаленному почтовому серверу через Интернет.

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

Возвращаясь к задаче, для отправки внешним почтовым системам необходим внешний (Internet) тип соединителя.

На следующей странице необходимо указать каким образом будет осуществляться отправка почты. Либо используя MX записи, либо выделенный смарт-хост в виде внешнего почтового релея.

Конфигурация доставки почтового соединителя Exchange

Внизу страницы присутствует чек-бокс с включением конфигурации Use the external DNS lookup settings on servers with transport roles. Задействование данной опции позволит не использовать конфигурацию DNS серверов сетевого интерфейса Exchange сервера, а применить настройки из конфигурации самого сервера. Они задаются на странице Servers, в первом же разделе Servers:

Настройка конфигурации сервера Exchange

Необходимая вкладка называется DNS lookups:

Задание внешних DNS серверов в Exchange

Следующий шаг заключается в задании адресного пространства, за которое ответственен соединитель. В случае если создаваемый тип соединителя внутренний или партнерский, задаться конкретный почтовый домен. Например, partnerdomain.com. Если же используется *, коннектор будет обсуживать все существующее пространство имен. Если в конфигурации присутствует несколько коннекторов, один из которых обслуживает пространство *, а второй с partnerdomain.com, приоритет получит последний.

Задание адресного пространства в соединителе отправки Exchange

Чек-бокс Scoped send connector даст возможность привязать коннектор к определенному сайту Active Directory, в котором находится сам Exchange. Для базовой настройки Exchange инфраструктуры этот параметр не требуется.

Задание адресного пространства выглядит следующим образом:

Указание адресного пространства в соединителе отправки Exchange

Далее, задаем сервер или сервера Exchange которые могут использовать данный соединитель:

Привязывание исходящего соединителя к серверу Exchange

В моем случае, у меня один и едиснтвенный Exchange сервер с ролью Hub Transport Service:

Указание сервера Exchange в соединителе отправки

Конфигурация исходящего соединителя завершена:

Созданный исходящий Exchange соединитель

Важно учесть, что со стороны сети, Exchange сервер должен иметь доступ по 25-му порту в Интернет (NAT). На Exchange сервер должен быть «проброшен» сделан DNAT с 25-го порта с публичного IP.  Публичный IP используемый в NAT и DNAT должны совпадать.

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

• Запись типа А должна иметь значение внешнего IP адреса, с которого сделан DNAT на приватный адрес Exchange сервера. В случае применения пограничного Edge сервера, DNAT делается на него;
• MX запись указывает на A запись.

Настройка внешних URL адресов Exchange сервера

Базовая настройка Exchange Server не заканчивается добавлением обслуживаемого домена и настройкой соединителей. Необходимо задать корректные URL адреса для подключения клиентов. Для этого перейдем в настройки конфигурации:

Настройка конфигурации сервера Exchange

Выберем сервер и нажмем на «карандаш» открыв страницу настроек. Далее, необходимо перейти в настройки Outlook Anywhere и задаем внешний домен для подключения клиентов:

Задание настроек Outlook Anywhere для Exchange

Данный домен, в последствии, будет использоваться для публикации Exchange сервера. Этот процесс будет описан в будущей статье.

Задание внешнего домена требуется и для веб каталогов Exchange сервера. Для этого необходимо перейти в конфигурацию virtual directories и найти «гаечный ключ»:

Задание внешнего домена для виртуальных каталогов Exchange

На открывшейся странице задаем необходимую конфигурацию:

Указание внешнего домена для виртуальных каталогов Exchange

Задание внешнего домена по которому будет доступна Exchange инфраструктура необходимо для дальнейшего выпуска SSL сертификатов.

На этом пока все. Если у вас возникли какие-либо вопросы, пожалуйста, пишите в комментарии.

Базовая настройка Exchange Server 2019. Часть 2

Zimbra — перенос почтовых ящиков

Столкнулся с задачей — необходимо перенести один из доменов на другой хост, думаю ок. Погуглил, нашел стандартные костыли типа zmmboxmove, думаю о как круто, все из коробки, но оказывается данное решение есть только в платной версии. Начал смотреть дальше, нашел миграцию с помощью встроенного механизма, но там теряются пароли пользователей, что минус, так как надо генерить новые, а это стресс для юзеров. В итоге было решено создать аналогичных пользователей или переместить с помощью встроенного механизма, а дальше перенести хеши паролей. По-быстрому решил заскриптовать, и вот что из этого вышло. Первым делом необходимо получить список аккаунтов, которые мы хотим перенести:

mkdir /tmp/zimbra
cd /tmp/zimbra
zmprov -l gaa example.com | grep -v [email protected] > users.txt

Далее нам необходимо получить хеши
pass.sh

#!/bin/bash
cat users.txt | while read line
do
    array[i]="$line"
    zmprov -l ga ${array[i]} userPassword | sed s/#\ name/zmprov\ ma/ | tr '\n' ' ' | sed s/:\ /\ \'/ | sed s/\ \ /\',/ | tr ',' '\n' >> /tmp/zimbra/restore_pass.sh
    let i++
done

После этого у нас есть файл с командами, которые устанавливают старые-новые хеши.
Экспортируем ящики
export. sh

#!/bin/bash
cat users.txt | while read line
do
    array[i]="$line"
    zmmailbox -z -m ${array[i]} -t 0 getRestURL "//?fmt=tgz" > /tmp/zimbra/${array[i]}.tar.gz
    let i++
done

Устанавливаем права на каталог

chmod -R 777 /tmp/zimbra/

Cливаем все что получилось на новый сервер и начинаем импортить ящики
import.sh

#!/bin/bash
cat users.txt | while read line
do
    array[i]="$line"
    zmprov ca ${array[i]} ZmHpg0LeQSPNZE0c
    zmmailbox -z -m ${array[i]} -t 0 postRestURL "//?fmt=tgz&resolve=reset" /tmp/zimbra/${array[i]}.tar.gz
    let i++
done

В этом шаге мы создаем ящики и сразу имортим в них содержимое, ну а далее просто остается установить хеши с помощью restore_pass.sh
Полезное:
Zmprov
Mailbox Password Migration

Сравнение Microsoft Exchange и Zimbra Collaboration

«Это настолько большая часть того, что я делаю каждый день, что я не задумываюсь об этом. По большей части это просто работает, пока не перестает» t, и в этом случае я звоню в техподдержку «. «Теперь нам удается обслуживать почти 99% информации». «Он очень хорошо интегрирован с другими программами Microsoft, командами и т. Д.. Они хорошо работают вместе». «Начальная настройка очень проста». «Легко настроить.« Дополнительные возможности Microsoft Exchange»

«Zimbra Collaboration проста в управлении. Он работает в операционной системе Linux, с которой гораздо лучше работать, чем с Microsoft Windows. Microsoft Exchange работает только на сервере Windows. Мы предпочитаем работать на сервере Linux из соображений безопасности и простоты управления. Zimbra Collaboration также имеет несколько интегрированных инструментов для обеспечения безопасности. Это несколько модулей для борьбы с вредоносными программами. Эти модули не очень мощные, но все же отлично справляются со своей задачей.Microsoft Exchange не имеет базового модуля. Вам необходимо приобрести защитное решение и добавить его в решение. Стоимость Zimbra Collaboration — еще одна причина, по которой это нравится. Кроме того, очень просто перейти с Zimbra Collaboration на другое решение для электронной почты ». Дополнительные преимущества Zimbra Collaboration»

«Обмен может быть немного привередливым, иногда или нестабильным. На прошлой неделе, например, я зашел в свой календарь, чтобы проверить некоторые брифинги, которые я установил, а затем вернулся в свой почтовый ящик, и внезапно вид изменился.Я понятия не имел, что я сделал, и не мог понять, как вернуть это представление. В результате я потерял продуктивность, пытаясь исправить это, потому что это было не то, что я хотел. Это было не то, с чем я привык работать. Два разных специалиста технической поддержки должны были работать со мной, чтобы вернуть представление к тому, что я хотел, просто чтобы я мог работать продуктивно ». « Когда мы начали использовать Exchange в облаке, у нас было много первоначальных проблем, связанных с наша основная база данных, и мы также столкнулись с проблемами, связанными, среди прочего, со случайным удалением почтовых ящиков. Фактически, многие файлы, которые мы переместили в облако, исчезли. Также, похоже, существует проблема с сохранением информации. « » Это не всегда лучшее решение с точки зрения интеграции с продуктами сторонних производителей. Он очень хорошо интегрируется с продуктами Microsoft, но не со сторонними продуктами. « » В имеющейся у нас версии я хотел бы улучшить связь между конечным устройством и сервером Exchange. « » Это не работает очень хорошо на виртуальной машине.Нам пришлось его переместить. Также возникают проблемы, когда вы пытаетесь переместить его между компьютерами ». Другие минусы Microsoft Exchange»

«Zimbra должна улучшить свое решение, чтобы упростить его, чтобы пользователям не приходилось использовать веб-почту для подключения к своим аккаунты и каждый раз входить в веб-почту. Это то, чего не хватает в Zimbra Collaboration. Они должны предоставить лучший способ легко подключить почтовые приложения на рабочем столе к серверу Zimbra. Им также следует попытаться иметь больше функций для управления хранилищем, например Microsoft Exchange.В настоящее время управление данными электронной почты должно выполняться вручную в Zimbra Collaboration, что нам очень сложно. Они должны обеспечивать способ сохранения электронных писем, чтобы у вас было больше места на сервере и в хранилище. Из-за отсутствия этой функции мы планируем перейти на Microsoft Exchange. Microsoft Exchange предоставляет лучший способ управления хранилищем, чем Zimbra Collaboration. У вас не может быть почтового решения без управления хранилищем, потому что количество писем всегда будет увеличиваться.Zimbra Collaboration также нуждается в инструментах для управления. Для управления всем почтовым ящиком и пространством требуется больше инструментов бэк-офиса. Вы управляете не только электронной почтой, но и документами, прикрепленными к ней. Следовательно, вам требуются инструменты для выбора и принятия решения о том, что вы хотите сохранить или как вы хотите освободить место в своей инфраструктуре ». Другие минусы совместной работы с Zimbra»

Zimbra — Настройка параметров нежелательной почты

• Справка
• Связаться

  Телефон

  +218 21 363 23 23

  Электронная почта

  продажи @ libyanspider. com

  Рабочие часы

  Суббота — Четверг

  9: 00–17: 00

  • Свяжитесь с нами
  • База знаний
• Блог

Мой аккаунт

• Логин
• Зарегистрироваться
• Забыли пароль?

доменов

• Домены
  • Все домены
    • Домены
    • Стоимость
    • Мои домены
    • Продлить домен
    • Зарегистрировать новый домен
    • Перенести домен к нам
  • Безопасность
    • SSL-сертификаты
    • Защита конфиденциальности домена
    • Защита веб-сайтов
    • Сертификат подписи кода
  • . LY Домены
    • Домены .ly
    • .LY Статистика
    • Взломать поисковый домен
    • Слова, оканчивающиеся на LY
  • Ссылки по теме
    • Премиум DNS
    • Клиентская зона
    • Реселлеры
• Облачные сервисы
  • Хостинг
    • Виртуальный хостинг
    • Виртуальные частные серверы
    • Выделенные серверы
    • Облачный хостинг
    • Премиум DNS
    • Выделенные IP-адреса
  • Электронная почта
    • Офис 365
    • G Suite
    • Почтовый сервер Zimbra
    • Сервер обмена
    • Решения для защиты от спама
  • PaaS
    • JPaaS
  • Служба резервного копирования
    • Диспетчер резервного копирования сервера
  • SaaS
    • Ratteb SIS
    • G Suite for Education
• Дизайн и разработка
  • Услуги
    • Брендинг
    • Веб-дизайн
    • Веб-разработка
    • Защита веб-сайтов
    • Мобильные приложения
  • WorkFlow
    • Рабочий процесс веб-дизайна
    • Стоимость веб-дизайна
    • Запросить предложение
  • Работа
    • Портфель
• Продукты
  • Безопасность
    • Касперский
    • Юбико

Перенос сервера совместной работы Zimbra на новый IP-адрес — журнал изменений Дэниела Меттлера

Вот краткий обзор того, как перенести почтовый сервер ZCS (на основе Ubuntu) на новый IP-адрес:

0) Здесь не рассматривается: настройка записей DNS. Убедитесь, что вы понизили TTL соответствующих записей DNS за пару дней до , чтобы минимизировать время простоя для клиентов (например, установите TTL 300 для 5-минутного простоя).

1) Установите новый IP-адрес в:
* Соответствующие записи DNS
* / etc / network / interfaces
* / etc / hosts
* Если ZCS работает в контейнере / виртуальной машине, не забудьте настроить его IP-адрес слишком.

2) Если новый IP-адрес является частью новой подсети, обязательно добавьте эту новую подсеть в ZCS trust_networks, в противном случае отправка (ретрансляция) сообщений через ZCS из Zimbra Desktop (или любого другого почтового клиента) не будет работать [ 1].Это можно установить с помощью интерфейса веб-администратора ZCS (например, https://mail.myserver.com:7071/zimbraAdmin/):
Перейдите в «Настройки сервера», затем откройте вкладку «MTA» и установите что-то подобное следующему в «Надежные сети MTA»:
127.0.0.0/8 wxyz / 26

3) Перезапустите сеть и службы ZCS (это важно, так как это также регулирует настройку trust_network в ZCS amavisd):
# /etc/init.