Что за программа exchange 2013 r4

Через три месяца после выхода Exchange 2013 CU3, Microsoft анонсировала выход Exchange 2013 SP1, который можно было бы назвать CU4. Вне всяких сомнений, анонс SP1 стал бальзамом на душу тех, кто уверен, что не стоит устанавливать серверные продукты Microsoft до выхода первого пакета обновлений. Хотя тем, кто придерживается принципа «поспешишь – людей насмешишь» приходится нелегко в облачном мире, предполагающем ежеквартальную установку обновлений и на корпоративные продукты, отказаться от старой привычки не так просто. В любом случае, сборка 847.32, или, проще говоря, Exchange 2013 SP1, доступен для загрузки.

Чтобы те, кто все еще работает с предыдущими версиями продукта не чувствовали себя забытыми, заодно вышли и Exchange 2007 SP3 RU13 с Exchange 2010 SP3 RU5.

Не хочу утомлять вас подробностями установки, поскольку, по крайней мере, для меня, обновление с CU3 прошло безболезненно. Тем не менее, напомню, что для поддержки новых командлетов и изменений в RBAC обязательно потребуется обновить схему ADDS, так что не забудьте включить этот шаг в ваш план установки. В силе остаются и проверенные временем предосторожности, такие как перевод члена DAG в Maintenance Mode и остановка EMS и EAC перед обновлением. В нашем случае обновление не закончилось травмами, что стало неожиданным приятным сюрпризом. Одно маленькое предупреждение – проверьте, что все службы запустились после обновления, поскольку с транспортными службами может быть подвох.

КАК МЫ ПОЛОЖИЛИ ПОЧТУ НА 4 ЧАСА при миграции EXCHANGE SERVER

UPD. Microsoft выпустила статью KB2938053, посвященную этой проблеме.

В пакет обновлений входят как доработки старого функционала, так и новые возможности. Возвращение поддержки S/MIME в OWA может быть примером первого, а появление в подсистеме DLP настроек маркирования (fingerprinting) важной информации – второго. Полный перечень обновлённого и добавленного функционала чуть ниже. Где это возможно и уместно, те же функции включены и в Office 365.

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

Итак, для меня наиболее интересными изменениями, включенными в SP1, будут следующие:

Появление протокола «MAPI over HTTP» (он же «алхимия») в качестве механизма взаимодействия Outlook и Exchange. В то время как RPC over HTTP по-прежнему используется для обслуживания клиентов, отличных от Outlook 2013 SP1, вероятнее всего MAPI over HTTP станет предпочтительным, а в дальнейшем и единственным протоколом для подключения к Exchange.

RPC – устаревший механизм, которому сложно справляться с неустойчивым сетевым соединением (например, в общедоступных Wi-Fi сетях), и отказ от его использования сделает клиентские подключения более надежными. MAPI over HTTP с использованием HTTPS основан на HTTP 1.1, и теперь клиенты используют команду POST для взаимодействия с сервером.

Новые возможности Exchange Server 2013

В результате Outlook, подключенный с использованием MAPI over HTTP, работает так же как и EWS, EAS или OWA, что позволяет лучше обрабатывать (надеюсь) такие сценарии как выход из гибернации, переключение между сетями или сетевыми адаптерами, сбои в сети и так далее. Для меня, возможно, это даже позволит больше не пользоваться OWA в режиме Offline.

Важно иметь в виду, что единственный почтовый клиент, поддерживающий MAPI over HTTP – Outlook 2013 SP1, поэтому нужно немало времени, чтобы организации полностью перешли на использование нового протокола. Вам так же потребуется однократно выполнить специальную настройку в вашей организации Exchange, чтобы включить использование MAPI over HTTP, к счастью это не нарушит сетевой обмен с клиентами RPC. В ближайшее время Microsoft планирует включить (если еще не включила) новый протокол в Office 365, и новые клиенты перейдут на его использование автоматически. Microsoft не планирует отключать RPC over HTTP для Office 365, но не удивительно если это произойдет в течении несколько лет.

OWA и OWA for Devices теперь отображают предупреждения DLP. Достаточно важное изменение, поскольку ранее Outlook 2013 был единственным клиентом, поддерживающим DLP. Зачастую это становилось блокирующим фактором при развертывании DLP на предприятии.
Заодно теперь можно добавлять любые документы в качестве набора информации, контролируемой политиками DLP на клиентах или с использованием транспортных правил. Для этого необходимо создать так называемый «отпечаток» (fingerprint) контролируемой информации. Замечу, что шаблоны DLP, поставляемые в комплекте Exchange 2013 SP1, теперь охватывают больше стран и регионов.

Возвращено журналирование командлетов в Exchange Administrative Center (EAC). Графическая MMC оснастка Exchange Management Console для Exchange 2007 или Exchange 2010 предоставляла три разных способа посмотреть какие командлеты (и с какими параметрами) будут исполнены при выполнении того или иного действия. Эта возможность незаменима для тех, кто хочет детально изучить синтаксис и параметры используемых командлетов. Наконец-то и в Exchange 2013 SP1 теперь можно включить журналирование и вывести в отдельное окно журнал командлетов, выполненных EAC.

ОС Windows 2012 R2 добавлена в список поддерживаемых операционных систем. Теперь вы можете устанавливать Exchange 2013 SP1 на серверы под управлением Windows 2012 R2, использовать контроллеры домена и глобальные каталоги на базе Windows 2012 R2, а так же повысить уровень домена и леса до Windows 2012 R2.
К слову, для Exchange 2007 SP3 RU13, Exchange 2010 SP3 RU5 так же добавлена поддержка контроллеров домена и глобальных каталогов на базе Windows 2012 R2, однако уровень домена и леса Windows 2012 R2 не поддерживается, как не поддерживается и установка продукта на Windows 2012 R2.

Упрощенное развертывание DAG. Если DAG развертывается на Windows 2012 R2, можно создать «DAG без выделенного IP -адреса» (или, в терминах Microsoft, «DAG without a Cluster Administrative Access Point). Это продолжение эволюции модели DAG, при которой всё большая часть ответственности за управление всеми аспектами DAG переносится на Exchange.

Новая модель предполагает, что всё управление DAG выполняется средствами Exchange, а оснастка Failover Cluster Management, CNO, сетевое имя и записи DNS для кластера больше не используются. Об этом крайне удобном изменении, упрощающем администрирование, я подробнее расскажу в ближайшее время. Напомню лишь, что все члены DAG должны работать на одной и той же версии операционной системы, поэтому если вы хотите перейти на использование Windows 2012 R2, имеющиеся DAG придется пересоздавать.

Возвращена поддержка S/MIME в OWA (только для IE9+, но не Chrome, Firefox и Safari). Этот функционал был удален в связи с внесением изменений в архитектуру OWA для поддержки различных типов дисплеев. В Exchange 2013 SP1 S/MIME поддерживается в Outlook, OWA и Exchange ActiveSync. Для включения поддержки S/MIME необходимо использовать командлет Set-OWAVirtualDirectory.

Роль Edge Transport возвращается, но в измененной форме. До Exchange 2013 SP1 для развертывания Edge-серверов (как правило, использующихся для непосредственного приема почты из Интернет) можно было использовать только Exchange 2010. Из-за того, что настройка и администрирование Edge в Exchange 2013 SP1 выполняется исключительно с использованием PowerShell, настройка существенно отличается от настройки аналогичной роли в Exchange 2007 или Exchange 2010, так что этому процессу следует уделить особое внимание и провести все необходимое тестирование и оценку до развертывания роли. Некоторые будут жаловаться на отсутствие GUI и необходимость управления Edge с использованием PowerShell, но в любом случае, процесс настройки достаточно прямолинеен, а если вы не можете справиться с несколькими командами PowerShell, может вам и не стоит развертывать сервер, который служит границей безопасности при приеме почты?

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

Возвращена поддержка SSL offloading. Вы снова можете перенести задачи по шифрованию SSL-подключений к серверам CAS на балансировщик.

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

Командная консоль Exchange

• Оболочка неожиданно загружает командлеты Exchange 2007 или Exchange 2010 Ранее открытие оболочки на сервере Exchange 2013 приводило к открытию подключения к локальному серверу или другому серверу под управлением Exchange 2013. При подключении загружаются командлеты Exchange 2013. Начиная с Exchange 2013 с накопительным пакетом обновления 11 (CU11), оболочка подключается к серверу Exchange Server, где находится почтовый ящик пользователя, выполнившего вход. Если у пользователя, выполнившего вход, нет почтового ящика, оболочка подключается к серверу, где находится почтовый ящик арбитража SystemMailbox. Целевым сервером может быть любая поддерживаемая версия Exchange. Это означает, что если вошедший в почтовый ящик пользователя (или почтовый ящик арбитража, если у пользователя нет почтового ящика) находится на сервере Exchange 2010, оболочка подключится к этому серверу и загрузит командлеты Exchange 2010. Это может помешать выполнению определенных задач, так как командлеты Exchange 2010 не могут управлять конфигурацией Или серверами Exchange 2013. Начиная с Exchange 2013 с накопительным пакетом обновления 11 (CU11), это поведение является конструктивным. Чтобы убедиться, что оболочка загружает командлеты Exchange 2013, переместите вошедший в систему почтовый ящик пользователя в Exchange 2013. Если у пользователя, выполнившего вход, нет почтового ящика, переместите почтовый ящик арбитража SystemMailbox на сервер Exchange 2013. Дополнительные сведения и сведения о перемещении почтового ящика арбитража см. в разделе Командная консоль Exchange и привязка почтовых ящиков в блоге команды Exchange.

Mailbox

• Серверы почтовых ящиков под управлением разных версий Exchange можно добавить в одну группу доступности базы данных . Командлет Add-DatabaseAvailabilityGroupServer и Центр администрирования Exchange неправильно позволяют добавлять сервер Exchange 2013 в группу доступности баз данных на основе Exchange 2016 и наоборот. Exchange поддерживает добавление в DAG только серверов почтовых ящиков с той же версией (например, Exchange 2013 и Exchange 2016). Кроме того, в Центре администрирования Exchange отображаются серверы Exchange 2013 и Exchange 2016 в списке серверов, доступных для добавления в DAG. Это может позволить администратору непреднамеренно добавить сервер с несовместимой версией Exchange в DAG (например, добавить сервер Exchange 2013 в daG на основе Exchange 2016). В настоящее время решения этой проблемы не существует. Администраторы должны быть внимательны при добавлении почтового ящика в DAG. Добавляйте только серверы Exchange 2013 в DAG на основе Exchange 2013 и только серверы Exchange 2016 в DAG на основе Exchange 2016. Версии Exchange указаны в столбце Версия в списке серверов в Центре администрирования Exchange. Ниже представлены версии серверов для Exchange 2013 и Exchange 2016:

• Exchange 2013 15.0 (сборка xxx.xx)
• Exchange 2016 15.1 (сборка xxx.xx)

• У вас есть несколько почтовых ящиков создания OAB в организации.
• Перед обновлением серверов клиентского доступа обновите серверы почтовых ящиков, на которых размещены почтовые ящики создания OAB.
• Вы обновляете серверы Exchange 2013 с выпуска до накопительного пакета обновления 5 до более поздней версии (например, обновление с Exchange 2013 с накопительным пакетом обновления 3 (CU3) до Exchange 2013 с накопительным пакетом обновления 6 (CU6).
• Серверы клиентского доступа работают под управлением выпуска, предшествующего накопительным пакетом обновления 5 (CU5).

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

Дополнительные сведения об изменениях автономной адресной области в Exchange 2013 с накопительным пакетом обновления 5 см. в статье Улучшения автономной адресной области в накопительном пакете обновления 5 для Exchange 2013.

Общедоступные папки

• Несанкционированные отправители больше не могут отправлять сообщения в общедоступные папки с поддержкой почты. До Exchange 2013 с накопительным пакетом обновления 6 (CU6) несанкционированные отправители могли отправлять сообщения в общедоступные папки с поддержкой почты. Это позволило внешним отправителям отправлять почту в общедоступные папки с поддержкой почты независимо от разрешений, заданных для общедоступной папки. Начиная с Exchange 2013 с накопительным пакетом обновления 6 (CU6), если вы хотите, чтобы внешние отправители отправляли почту в общедоступные папки с поддержкой почты, анонимный пользователь должен иметь по крайней мере разрешение на создание элементов . Если вы настроили общедоступные папки с поддержкой почты и не сделали этого, внешние отправители получат уведомление о сбое доставки, а сообщения не будут доставлены в общедоступную папку с поддержкой почты. Настроить разрешения для анонимного пользователя можно с помощью командной консоли или приложения Outlook. Дополнительные сведения о настройке разрешений для анонимного пользователя см. в разделе Mail-enable or mail-disable a public folder.
• Максимальное количество общедоступных папок, которые можно перенести в Exchange 2013 с устаревших серверов Exchange Server, составляет 500 000. Дополнительные сведения о переносе общедоступных папок см. в статье Использование пакетной миграции для переноса общедоступных папок в Exchange 2013 из предыдущих версий.

Поток обработки почты

• Командлетам TransportAgent на серверах клиентского доступа требуется локальная Windows PowerShell. Существует проблема с командлетами *-TransportAgent, которая не позволяет этим командлетам устанавливать, удалять агенты транспорта на серверах клиентского доступа и управлять ими с помощью командной консоли Exchange. Чтобы установить, удалить агенты транспорта и управлять ими на серверах клиентского доступа, необходимо вручную загрузить оснастку Exchange Windows PowerShell, а затем запустить командлеты *-TransportAgent. При попытке установить, удалить агенты транспорта или управлять ими с помощью командной консоли Exchange изменения будут применены к серверу почтовых ящиков Exchange 2013, к которому вы подключены. Чтобы установить, удалить агенты транспорта или управлять ими на серверах клиентского доступа, выполните следующие действия на сервере клиентского доступа, которым вы хотите управлять.

Предупреждение Microsoft.Exchange.Management.PowerShell.SnapIn Загрузка оснастки Windows PowerShell и выполнение командлетов, отличных от командлетов -TransportAgent, не поддерживается и может привести к непоправимому ущербу для развертывания Exchange. Необходимо быть локальным администратором на сервере клиентского доступа, на котором вы хотите установить, удалить агенты транспорта или управлять ими. Мы не поддерживаем изменение списков управления доступом (ACL) в файлах Exchange, каталогах или объектах Active Directory.

Важно! Выполните следующую процедуру только на серверах клиентского доступа. Вам не нужно загружать оснастку Exchange Windows PowerShell, если вы хотите управлять агентами транспорта на серверах почтовых ящиков.

1. Откройте новое окно Windows PowerShell.
2. Выполните следующую команду.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

Возможность подключения клиента

• Проверка подлинности NTLM завершается ошибкой для клиентов, не присоединенных к домену. Проверка подлинности между клиентом, например Почта Windows Live, и Exchange 2013 может завершиться ошибкой при выполнении следующих условий:

• Затем клиент использует метод проверки подлинности NTLM.
• Компьютер не присоединен к домену.

Чтобы обойти эту проблему, можно выполнить одно из следующих действий:

• Присоединение компьютера, на котором работает клиент, к домену.
• Измените тип проверки подлинности, который использует клиент, с NTLM на Обычная проверка подлинности по ПРОТОКОЛу TLS.

• Источник: MSExchangeFrontEndTransport
• Идентификатор события: 1035
• Описание. Сбой входящей проверки подлинности с ошибкой IllegalMessage для имени> внешнего < сервера клиента соединителя получения. Механизм проверки подлинности — Gssapi. Исходный IP-адрес клиента, который пытался пройти проверку подлинности в Exchange, — [IP-адрес> клиента].

Чтобы обойти эту проблему, необходимо удалить Integrated метод проверки подлинности из соединителя получения клиента на серверах клиентского доступа Exchange 2013. Чтобы удалить Integrated метод проверки подлинности из соединителя получения клиента, выполните следующую команду на каждом сервере клиентского доступа Exchange 2013, который может получать подключения с компьютеров, выполняющих командлет Send-MailMessage :

Set-ReceiveConnector «Client Frontend » -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS

Примечание. Эта проблема возникает только в том случае, если на серверах клиентского доступа включен протокол MAPI через HTTP. По умолчанию она отключена. Если параметр MAPI через HTTP отключен, клиенты используют вместо этого протокол RPC через HTTP.

1. На серверах с ролью сервера клиентского доступа выполните в командной строке Windows следующие команды:

set AppCmdLocation=%windir%System32inetsrv set ExchangeLocation=%ProgramFiles%MicrosoftExchange ServerV15 %AppCmdLocation%appcmd.exe SET AppPool «MSExchangeMapiFrontEndAppPool» /CLRConfigFile:»%ExchangeLocation%binMSExchangeMapiFrontEndAppPool_CLRConfig.config» %AppCmdLocation%appcmd.exe RECYCLE AppPool «MSExchangeMapiFrontEndAppPool»
set AppCmdLocation=%windir%System32inetsrv set ExchangeLocation=%ProgramFiles%MicrosoftExchange ServerV15 %AppCmdLocation%appcmd.exe SET AppPool «MSExchangeMapiMailboxAppPool» /CLRConfigFile:»%ExchangeLocation%binMSExchangeMapiMailboxAppPool_CLRConfig.config» %AppCmdLocation%appcmd.exe RECYCLE AppPool «MSExchangeMapiMailboxAppPool» %AppCmdLocation%appcmd.exe SET AppPool «MSExchangeMapiAddressBookAppPool» /CLRConfigFile:»%ExchangeLocation%binMSExchangeMapiAddressBookAppPool_CLRConfig.config» %AppCmdLocation%appcmd.exe RECYCLE AppPool «MSExchangeMapiAddressBookAppPool»

Сосуществование Exchange 2010

• Запросы на доступ к почтовым ящикам Exchange 2010 могут не работать, если они проходят через серверы клиентского доступа Exchange 2013. В некоторых ситуациях запрос прокси-сервера между серверами клиентского доступа Exchange 2013 и Exchange 2010 с пакетом обновления 3 (SP3) без установленных накопительных пакетов обновления может работать неправильно, и появится ошибка. Это может произойти, если выполняются все следующие условия:

• Пользователь с почтовым ящиком Exchange 2013 пытается открыть почтовый ящик Exchange 2010 одним из следующих методов:

• Параметр Открыть другой почтовый ящик в Outlook Web App -OR-
• Параметр Другой пользователь в Центре администрирования Exchange
• Сервер клиентского доступа, к которому подключен пользователь, работает под управлением Exchange 2013.
• Сервер клиентского доступа Exchange 2010 был обновлен до Exchange 2010 с пакетом обновления 3 (SP3) с момента выпуска до выпуска (RTM) версии Exchange 2010 или предыдущего пакета обновления Exchange 2010.

Если все описанные выше условия выполняются, пользователь не сможет получить доступ к параметрам Outlook Web App exchange 2010 другого пользователя, и может появиться пустая страница.

Чтобы обойти эту проблему, установите накопительный пакет обновления 1 (SP3) для Exchange 2010 или более поздней версии на каждом сервере Exchange 2010.

Источник: learn.microsoft.com