Русский блог Microsoft Exchange https://docs.microsoft.com/archive/blogs/exchange_ru/feed.xml Thu, 03 Aug 2017 11:48:43 GMT en-US hourly 1 Пересылка собраний и Meeting Forward Notification https://docs.microsoft.com/archive/blogs/exchange_ru/meeting-forward-notification Wed, 10 May 2017 10:05:09 GMT https://blogs.technet.microsoft.com/exchange_ru/?p=5315 Представим ситуацию - один пользователь создает собрание и приглашает в него другого участника, а тот в свою очередь добавляет своего коллегу к этой же встрече путем перенаправления (forward) ему оригинального приглашения. Вопрос - что произойдет, если новый участник не ответил на приглашение (принять\отклонить), при этом организатор изменяет , время\дату встречи? Ответ - оба участника получат обновление встречи.   Как это работает? Существует процесс оповещения организатора встречи о том, что его приглашение было перенаправлено третьему лицу. Работает это на базе служебных сообщений с классом IPM.Schedule.Meeting.Notification.Forward. Такие сообщения генерируются на стороне службы транспорта в момент отправки перенаправленной встречи, либо непосредственно в Outlook`е пользователя (поведение различается для разных сценариев). Как только Attendee1 делает Forward встречи, происходит следующее:
  1. Из его ящика отправляется перенаправленное письмо в сторону второго участника
  2. От имени MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@contoso.com либо от имени самого Attendee1 отправляется сообщение с типом Meeting Forward Notification (MFN) в сторону организатора:
mfn1    mfn2 Как только в ящик организатора доставляется MFN сообщение, список участников встречи обновляется автоматически, не требуя вмешательства самого организатора (в ряде случаев организатор видит MFN сообщение у себя во Входящих, но чаще письмо перемещается в Удаленные автоматически).   Усложним сценарий и представим, что Организатор и первый участник находятся в разных организациях. mfn3 В результате мы ожидаем, что в данной встрече будут присутствовать также три пользователя, как и раньше. Но здесь есть нюанс.   Вопрос - что произойдет, когда организатор изменит, время\дату встречи? Ответ: С первым участником все понятно, ему придет обновление для текущего события с новым временем. А вот со вторым участником, есть варианты:
  • Если он уже принял перенаправленное приглашение от своего коллеги и соответствующее сообщение было доставлено в ящик организатора, то он тоже получит обновление
  • Если не принял, то вероятнее всего у него встреча останется на старом месте (в отличии от первого сценария)
  Тонкий момент здесь заключается в том, что по умолчанию в организации Exchange отправка Meeting Forward Notification в Интернет запрещена (в разных версиях сервера Exchange поведение по умолчанию может различаться). В результате, MFN сообщение не будет доставлено в ящик организатора, т.к. не сможет выйти за пределы организации Fabricam.com.   Конфигурируется это на стороне Remote Domain -> MeetingForwardNotificationEnabled (True \ False). Чтобы MFN ходили во внешний мир, нужно либо изменить Default Remote Domain, либо создать для партнерской организации новый и изменить его параметр MeetingForwardNotificationEnabled в True только для него:
Set-RemoteDomain default -MeetingForwardNotificationEnabled $True
Кроме того, замечено, что в ряде случаев MFN сообщения не обрабатываются автоматически на стороне Организатора. Это происходит потому, что в процессе передачи письма через Интернет, у него теряется класс IPM.Schedule.Meeting.Notification.Forward, и оно приходит как обычное письмо. Чтобы этого избежать, я рекомендую проверить настройку TNEF для данного Remote Domain`a. Лучше создать новый домен и выставить TNEFEnabled $True только для него:
Set-RemoteDomain contoso.com -TNEFEnabled $True
Полезные ссылки:
  • Behavior of Meeting Forward Notifications
https://blogs.technet.microsoft.com/mr_proactive/2012/05/02/behavior-of-meeting-forward-notifications/
  • Best practices when using the Outlook Calendar
https://support.office.com/en-us/article/Best-practices-when-using-the-Outlook-Calendar-D93F72D3-2361-4E0D-8D6A-5C4939C17F39]]> Exchange 2013 - Server Component State https://docs.microsoft.com/archive/blogs/exchange_ru/exchange-2013-server-component-state Sun, 31 May 2015 03:01:01 GMT https://blogs.technet.microsoft.com/exchange_ru/2015/05/31/exchange-2013-server-component-state/ В Exchange 2013 была анонсирована новая концепция управления состоянием серверов и сервисов Exchange в рамках организации – “Server Component State”. Бывают ситуации, когда нужно вывести сервер из обслуживания, но при этом оставить сервисы на нем в рабочем состоянии. Кроме того, функции Managed Availability (Health Manager) также нужно иметь возможность гибко управлять состоянием компонентов и сервисов на отдельно взятых серверах.

Несмотря на то, что принцип работы механизма ServerComponentState довольно прост, иногда возникают сложности в при его использовании. Далее мы рассмотрим распространённую ситуацию, когда с точки зрения командлета Get-ServerComponentState все компоненты находятся в состоянии Active, а с точки зрения сервиса Exchange (например, транспорта) – нет.

 

Немного теории:

Информация о состоянии компонентов хранится в двух местах:

  • Active Directory – атрибут msExchComponentStates у объекта сервера

 

  • Реестр сервера – ветка HKLM\Software\Microsoft\ExchangeServer\v15\ServerComponentStates

 

Получить текущее состояние компонентов для сервера можно командой:

Get-ServerComponentState -Identity <имя сервера>

Кроме того, есть такое понятие как Requester, грубо говоря, при помощи requester`a мы показываем зачем мы изменили состояние компонента. Есть следующе типы Requester`ов:

  • HealthAPI

  • Maintenance

  • Sidelined

  • Functional

  • Deployment

 

Вот именно с этого момента обычно и начинаются проблемы, дело в том, что Requester`ы являются независимыми и у каждого компонента может быть несколько записей разных Requester`ов, при этом они могут иметь разные значения Active и Inactive одновременно. Приоритет отдается Inactive состояниям!

Пример:

Механизм Managed Availability по какой-то причине отключил компонент Hub Transport, а Вы его включили (например, через Requester Functional). В результате у компонента будет две записи от разных Requester`ов с разным состоянием, и он не окажется активным до тех пор, пока все записи не будут иметь 1 в своем значении.

Ситуация осложняется в том случае, если в момент изменения состояния произошли проблемы с репликацией данных в АД и значения в реестре и в Active Directory расходятся, например, вот так:

В результате администратор считает, что компонент активен, а сама служба транспорт – что нет. В итоге транспорт на этой ноде будет работать не корректно.

 

Резюме

Чтобы быть уверенным, что все компоненты включены, нужно руками проверять данные в реестре и в Active Directory. Облегчить задачу можно при помощи следующего скрипта: 

  • Записываем в переменную состояние компонентов сервера

$component_states  = Get-ServerComponentState -Identity <имя сервера>

  • Получаем значение компонентов из реестра

$component_states.localstates

  • Получаем значение компонентов из ActiveDirectory

$component_states.remotestates

Как мы видим, значения различаются. Для того, чтобы исправить проблему в данном случае, нужно перевести компонент HubTransport в состояние Active через Requester HealthAPI ещё раз:

Set-ServerComponentState <имя сервера> -Component HubTransport -State active -Requester HealthAPI

 

Если у вас есть вопросы\предложения\пожелания, добро пожаловать в комменты.

 

Alexey Bogomolov,

CTS Support Escalation Engineer, Microsoft.

]]> Очистка транспортной очереди Exchange с большим количеством элементов https://docs.microsoft.com/archive/blogs/exchange_ru/exchange-1089 Sun, 31 May 2015 01:00:49 GMT https://blogs.technet.microsoft.com/exchange_ru/2015/05/31/exchange-1089/ Однажды так случилось, что в транспортной очереди на сервере Exchange скопилось ну очень много писем – несколько сотен тысяч. Ввиду того, что письма эти были сгенерированы и разослан по ошибке, доставлять их было не нужно, а нужно было удалить. Казалось бы, все просто – есть статья на TechNet, которая рассказывает, как это сделать - White Paper: Remove Specific Messages from Exchange Server - https://technet.microsoft.com/en-us/library/hh547012(v=exchg.141).aspx#removeMQ. Т.е. план такой:
  • Ставим службу транспорта на паузу, чтобы сервер не принимал больше новых писем, но при этом мог обрабатывать имеющиеся:

net pause MsExchangeTransport

  • Далее получаем список элементов в очереди нужного нам сервера и удаляем их:

Get-TransportServer <имя сервера> | Get-Queue | Get-Message -ResultSize unlimited | Where {$_.Subject -eq "Surprise Party"} | Remove-Message -WithNDR $False

в качестве фильтра можно использовать и другое условие, или не использовать фильтр вовсе.

Вроде все просто, но в случае с большим количеством элементов в очереди, вы получите ошибку вида:

The query produced too many results. To reduce the number of results, use a more restrictive filter.
   + CategoryInfo          : InvalidOperation: (:) [Get-Message], LocalizedException
   + FullyQualifiedErrorId : 88B8D789,Microsoft.Exchange.Management.QueueViewerTasks.GetMessageInfo

Чтобы обойти эту ошибку, я предлагаю попробовать использовать следующую конструкцию:

Get-Message -filter {Subject -eq "…"} -resultsize 1000 | remove-Message -withNDR $False

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

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

Sending data to a remote command failed with the following error message: The total data received from the remote client exceeded allowed maximum. Allowed maximum is 524288000. For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OperationStopped: (System.Manageme...pressionSyncJob:PSInvokeExpressionSyncJob) [], PSRemotingTransportException
    + FullyQualifiedErrorId : JobFailure

Чтобы обойти это ограничение, нужно изменить этот лимит в настройках виртуального каталога PowerShell (в IIS) на том сервере, куда подключилась консоль. Нужно поменять два атрибута в файле web.config - PSMaximumReceivedObjectSizeMB и PSMaximumReceivedDataSizePerCommandMB.

Нажмите на виртуальный каталог powershell правой кнопкой -> Explore, в открывшейся папке Вы найдете web.config (для Exchange 2013 надо смотреть на Back-End`e):

           <InitializationParameters>
             <Param Name="PSVersion" Value="2.0" />
             <Param Name="ApplicationBase" Value="%ExchangeInstallPath%Bin" />
             <Param Name="AssemblyName" Value="Microsoft.Exchange.Configuration.ObjectModel.dll" />
             <Param Name="PSSessionConfigurationTypeName" Value="Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin" />
             <Param Name="PSMaximumReceivedObjectSizeMB" Value="75" />
             <Param Name="PSMaximumReceivedDataSizePerCommandMB" Value="500" />
           </InitializationParameters>

Далее выполнить IISRESET

!После выполнения работ желательно значения этих атрибутов вернуть в дефолтные.

Если у вас есть вопросы\педложения\пожелания, или вы столкнулись с другим типом ошибки при выполнении подобных действие - добро пожаловать в комментарии.

Alexey Bogomolov,

CTS Support Escalation Engineer, Microsoft

]]> The certificate status could not be determined because the revocation check failed https://docs.microsoft.com/archive/blogs/exchange_ru/the-certificate-status-could-not-be-determined-because-the-revocation-check-failed Thu, 17 Apr 2014 06:51:00 GMT https://blogs.technet.microsoft.com/exchange_ru/2014/04/17/the-certificate-status-could-not-be-determined-because-the-revocation-check-failed/ В Интернете много статей, которые рассказывают о том, как бороться с ошибкой "The certificate status could not be determined because the revocation check failed", но к сожалению, мне не удалось найти ту, которая описывала бы мою проблему, так что я решил написать эту короткую заметку.

 

Начнем с того, что сообщения в графической консоли поводу ошибки в сертификате совсем не означает, что сертификат нельзя назначить на нужные сервисы. Exchange Management Shell не выполняет подобных проверок и через EMS вы легко можете достичь желаемого:

  •  Get-ExchangeCertificate
  • Копируем Thumbprint
  • Enable-ExchangeCertificate -Thumbpring <отпечаток, полученный выше> -Services SMTP,IIS,IMAP

 

Далее, почему такая ошибка может быть

 

Дело все в том, что в Exchange Management Console есть процедура проверки сертификатов и одним из шагов данной проверки является проверка на "отозванность", т.е. серверу нужно скачать Certificate Revocation List (CRL), выпущенный центром сертификации, выдавшим данный сертификат, и убедиться, что в этом листе нет текущего сертификата.

 

Откуда будем качать CRL?

В каждом сертификате есть специальное поле CRL Distribution Points, где обозначено откуда можно скачать CRL:

 

 

Для доступа в Интернет по HTTP, Exchange использует настройки прокси сервера, указанные в системе, посмотреть можно через

netsh winhttp show proxy

Подробнее про WinHttp и как это настроить читайте здесь - https://support.microsoft.com/kb/979694

Соответственно на прокси должен быть разрешен выход в Интернет для данного сервера.

 

Как проверить сертификат?

 

Для начала попробуем открыть ссылку, указанную в CRL Distribution Point, прямо в браузере - должен загрузиться соответствующий файл (у меня открылся)

 

Далее следует выполнить очистку CRL и OCSP кэшей:

 

Certutil -urlcache ocsp delete
certutil -urlcache crl delete 

 

После этого можно проверить сертификата через утилиту Certutil:

  • Экспортируйте сертификат в файл (без закрытого ключа)
  • Выполните команду

Certutil -url <certificate file name>

  •  Нажмите кнопку Retrieve
  • В результате статус для Base CRL и Delta CRL должен быть Verified

 

Видим, что есть ещё и CRL+ - это собственно Delta CRL, который мы конфигурировали на СА. Чтобы понять почему в данном случае не проходит проверка Delta CRL я ещё раз открыл консоль управления Exchange с включенным Network Monitor`ом и вот что получилось:

 

 

Выходит, что IIS отвечает File Not Found, хотя при этом файл в каталоге есть.

После не продолжительных поисков стало понятно, что по умолчанию IIS блокирует ссылки в которых есть знак "+". Для того, чтобы разрешить IIS принимать запросы, у которых в адресе указан знак “+”, откроем командную строку (cmd) от имени администратора на сервере с установленным центром сертификации и выполняем команду:

 

%windir%\system32\inetsrv\appcmd set config /section:requestfiltering /allowdoubleescaping:true

 

После чего следует перезапустить службу Microsoft.Exchange.ServiceHost и открыть консоль заново.

В моем случае это решило проблему. Если у вас проблема сохраняется - мы можем обсудить это в комментариях к статье.

Alexey Bogomolov,

Microsoft Engineer,

Customer Service and Support

]]> объявление https://docs.microsoft.com/archive/blogs/exchange_ru/24 Fri, 07 Jun 2013 02:14:28 GMT https://blogs.technet.microsoft.com/exchange_ru/2013/06/07/24/ 20 июня 2013 г. корпорация Майкрософт прекратит публикацию контента в этом блоге (хотя архивные сообщения останутся доступны). В будущем сведения IT Pro для Microsoft Exchange Server ищите в блоге https://blogs.technet.com/b/exchange.

]]> Загадочный цикл почты на пограничном транспортном сервере: проверьте ограничения размера https://docs.microsoft.com/archive/blogs/exchange_ru/34 Wed, 08 May 2013 23:30:22 GMT https://blogs.technet.microsoft.com/exchange_ru/2013/05/08/34/

Исходная статья опубликована в пятницу, 29 марта 2013 г.

Я инженер технической поддержки в CSS. Я работал с клиентом, который сообщил об ошибке цикла почты для конкретного домена, такого как contoso.com. Эта ошибка наблюдалась только в больших сообщениях электронной почты. Да, это действительно выглядело загадочно, пока не выяснилось, что цикл почты был вызван ограничением размера в соединителе отправки. Я думаю, это было достаточно интересно, чтобы поделиться.

Сведения о конфигурации и коренная причина проблемы

Сначала я подумал, что это может быть результатом того, что пограничный сервер настроен для использования внешнего DNS-сервера (DNS-сервера, который разрешает внешние узлы). Обычно когда пограничный транспортный сервер настроен для использования внешней службы доменных имен (DNS), он разрешает доменное имя в общие IP-адреса (как правило, указывая на себя, на внешний брандмауэр или на поставщика услуг) вместо транспортного сервер-концентратора на сайте Active Diectory, что приводит к циклу почты.

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

clip_image002

 

В этом сценарии происходит следующее. Когда пограничный транспортный сервер получает сообщение электронной почты размером в 20 МБ от отправителя в Интернете, он принимает это сообщение. Пограничный транспортный сервер имеет два соединителя, соответствующие адресным пространствам — один для адресного пространства contoso.com на сайте Active Directory, а другой для адресного пространства *. Когда решение о маршрутизации зависит от всех доступных соединителей, один из них от пограничного сервера к серверу-концентратору не учитывается из-за ограничения размера (он имеет ограничение 10 МБ). Лучшим соответствием оказывается соединитель * от пограничного сервера в Интернет, который имеет ограничение на размер сообщений в 30 МБ (см. описание алгоритма выбора соединителя в статье Общие сведения о маршрутизации сообщений).

Результат: сообщение перенаправляется обратно в Интернет, и возникает цикл сообщения между Интернетом и пограничным сервером.

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

При использовании DNS:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ## (записи DNS для этого домена настроены в цикле)

При использовании промежуточного узла:

5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP# (Число прыжков превышено — возможен цикл почты)

Решение

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

  • Установить для параметра MaxMessageSize в соединителе получения (который получает входящую почту из Интернета) значение 10MB, чтобы сообщения из Интернета были ограничены размером в 10 МБ.
  • Установить для параметра MaxMessageSize в соединителе отправки из пограничного сервера на сервер-концентратор значение 30MB, которое позволит получать от внешних отправителей сообщения размером до 30 МБ.

Загадка разрешена! Мои благодарности Ариндему Токдеру (Arindam Thokder) и Скотту Лендри (Scott Landry), которые помогли мне подготовить эту публикацию для блога!

Суреш Кумар (Suresh Kumar) (XCON)

Это локализованная запись блога. Исходная статья находится по адресу Mysterious mail loop on Edge Transport server: Check your size limits!

]]> Объявление о выходе Microsoft Connectivity Analyzer (MCA) 1.0 и Microsoft Remote Connectivity Analyzer (RCA) 2.1 https://docs.microsoft.com/archive/blogs/exchange_ru/microsoft-connectivity-analyzer-mca-1-0-microsoft-remote-connectivit Wed, 08 May 2013 23:30:20 GMT https://blogs.technet.microsoft.com/exchange_ru/2013/05/08/microsoft-connectivity-analyzer-mca-1-0-microsoft-remote-connectivit/

Исходная статья опубликована во вторник, 12 марта 2013 г.

Еще в ноябре 2012 г. мы объявили о выходе бета-версии клиента MCA. Мы были очень заняты, работая над улучшением возможностей тестирования, доступных в клиенте MCA. Вот что мы построили для версии 1.0:

рисунок 

Инструмент Microsoft Connectivity Analyzer 1.0

Мы рады объявить о выпуске 1.0 Microsoft Connectivity Analyzer. Этот инструмент является дополнением к веб-сайту Microsoft Remote Connectivity Analyzer. Инструмент MCA предоставляет администраторам и пользователям возможность выполнения диагностики подключения для пяти распространенных симптомов подключения непосредственно с их локального компьютера. Пользователи могут тестировать свое собственное подключение и сохранять результаты в формате HTML, а администраторы могут исследовать их при присмотре результатов на веб-сайте RCA.

Установить MCA 1.0 можно здесь: https://testconnectivity.microsoft.com/?tabid=client

Посмотреть вводный видеоролик:

Инструмент MCA предлагает пять симптомов тестирования.

  • “Я не могу войти в Office Outlook” — этот тест аналогичен тесту Exchange RCA для мобильного Outlook (RPC over HTTP). Это возможность запуска теста SSO, предоставленная на странице параметров.
  • “Я не могу отправлять или получать электронную почту на моем мобильном устройстве”. — этот тест аналогичен тесту Exchange RCA для Exchange ActiveSync.
  • ***Новый тест MCA*** “Я не могу войти в Lync с моего мобильного устройства или из приложения Lync из Магазина Windows” — этот тест проверяет записи сервера доменных имен (DNS) для вашего локального домена, чтобы убедиться в правильности их настройки для поддержки клиентов мобильных устройств Lync. Также он подключается к веб-службе автообнаружения и проверяет правильность настройки проверки подлинности, сертификата и веб-службы для мобильных устройств.
  • ***Новый тест MCA*** “Я не могу получать или отправлять электронную почту в Outlook (только Office 365)” — этот тест проверяет входящий и исходящий поток обработки почты SMTP, а также включает проверки сервера доменных имен для клиентов O365.
  • ***Новый тест MCA*** “Я не могу просматривать сведения о доступности другого пользователя” — этот тест проверяет, может ли почтовый ящик Office 365 получать доступ к сведениям о доступности локального ящика, и наоборот (одно направление на одно выполнение теста).

clip_image002

Инструмент Microsoft Lync Connectivity Analyzer: Вы также заметите инструмент Lync Connectivity Analyzer на странице клиента. Мы работаем над объединением MCA и MLCA в ближайшем будущем, но хотели сделать эти два прекрасных инструмента доступными для клиентов уже сейчас, чтобы улучшить наши возможности диагностики клиента. Дополнительные сведения о MLCA см. ЗДЕСЬ.

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

image

Microsoft Remote Connectivity Analyzer 2.1

Мы рады объявить о выпуске версии 2.1 веб-сайта Microsoft Remote Connectivity Analyzer. Этот инструмент предоставляет администраторам и пользователям возможность выполнения диагностики подключения для наших серверов, чтобы проверить распространенные проблемы с Exchange, Lync и Office 365. Мы добавили новые тесты сервера доменных имен Office 365, усовершенствовали существующие тесты и улучшили взаимодействие на сайте в целом.

Обновления этого веб-сайта проверяйте здесь: https://testconnectivity.microsoft.com

Ключевые аспекты выпуска 2.1 RCA

Версия 2.1 (март 2013 г.)

  • Добавлена поддержка 60 языков с локализацией
  • Обновлена версия загружаемого инструмента Microsoft Connectivity Analyzer v1.0 для устранения неполадок подключения с локального компьютера
  • Добавлен загружаемый инструмент Microsoft Lync Connectivity Analyzer для устранения проблем с Lync с локального компьютера
  • Добавлен раздел главных тестов Office 365
  • Добавлен тест подключения для сервера доменных имен (DNS) Exchange Office 365

clip_image001

Удачи!

Спасибо.

Брайан Фек (Brian Feck) от имени всей группы MCA/RCA.
Канал этой группы в Twitter — @ExRCA

Это локализованная публикация в блоге. Исходная статья находится по адресу Remote Connectivity Analyzer gets an updated CAPTCHA experience.

]]> Доступно руководство по размещению и мультитенатности для Exchange Server 2013 https://docs.microsoft.com/archive/blogs/exchange_ru/54 Wed, 08 May 2013 21:01:00 GMT https://blogs.technet.microsoft.com/exchange_ru/2013/05/08/54/ Исходная статья опубликована в четверг 21 февраля 2013 г.

Мы рады возможности объявить о появлении часто запрашиваемого руководства по размещению и мультитенантности для Exchange Server 2013. Этот документ можно загрузить здесь.

Как заметит внимательный читатель, это руководство очень похоже на руководство для Exchange Server 2010. Это не потому, что мы только находили, копировали и заменяли, а потому, что стратегия, на которой мы остановились для Exchange 2010, остается в силе для Exchange 2013. Стратегия заключается в том, что вы должны только настраивать свои решения с помощью встроенных инструментов, командлетов и интерфейсов, и ни при каких обстоятельствах не должны непосредственно манипулировать объектами в AD для создания нужной конфигурации.

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

Стержнем важного элемента сегментации каталогов вашего решения является компонент "Политика адресной книги". С недавним объявлением об агенте транспорта, созданном для получения преимуществ политик адресной книги, мы надеемся, вы найдете, что ваше решение 2013 стало еще проще строить и обслуживать.

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

Как и в Exchange 2010, у нас есть партнерские решения, построенные в соответствии с рекомендациями в документе, и решения, которые в настоящее время нами проверены, перечислены на этом сайте. Этот список будет расти, так что если нужное вам решение в настоящий момент отсутствует в списке, то периодически проверяйте список, или обратитесь к поставщику и спросите его о его планах относительно проверки.

Мы планируем выпустить масштабное руководство по Exchange 2013, настроенном для мультитенантности или размещения, и обновим сайт решений, когда этот документ будет доступен.

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

Грег Тейлор (Greg Taylor),
старший руководитель программы, отвечающий за
взаимодействие с клиентами Exchange

Это локализованная запись блога. Исходная статья находится по ссылке Hosting and Multi-Tenancy Guidance for Exchange Server 2013 Now Available

]]> Управление автономной адресной книгой в Exchange Server 2013 https://docs.microsoft.com/archive/blogs/exchange_ru/64 Thu, 31 Jan 2013 07:31:00 GMT https://blogs.technet.microsoft.com/exchange_ru/2013/01/31/64/ Исходная статья опубликована во вторник, 15 января 2013 г.

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

Управление автономной адресной книгой (OAB) и ее администрирование отличаются в Exchange 2013 из-за изменений в архитектуре. Кроме того, в новом Центре администрирования Exchange в настоящее время нет возможностей для управления автономными адресными книгами. Это означает, что для выполнения задач, связанных с автономными адресными книгами, вам пока придется использовать командную консоль Exchange.

В этой статье рассматриваются стандартные задачи администрирования OAB и для наглядности приводится несколько реальных сценариев.

Примечание. Если вы используете доменную среду Active Directory с несколькими лесами, параметр ViewEntireForest сеанса консоли должен быть включен. В противном случае некоторые из команд в этой статье не вернут выходные данные.

Чтобы включить параметр ViewEntireForest, выполните следующую команду:

Set-ADServerSettings -ViewEntireForest $true

Создание автономной адресной книги

При создании автономной адресной книги в Exchange 2013 параметр -Server больше не используется. Чтобы создать автономную адресную книгу, вам нужно указать только требуемые списки адресов.

В следующем примере создается автономная адресная книга для списка адресов с именем "Глобальный список адресов FAB".

New-OfflineAddressBook -Name OAB-FAB -AddressLists "Глобальный список адресов FAB"

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

Арбитражным почтовым ящикам в Exchange Server 2013 назначаются "постоянные возможности", определяющие назначение или функцию арбитражного почтового ящика.

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

Сервер почтовых ящиков Exchange Server 2013, на котором размещен почтовый ящик организации, формирует все автономные адресные книги, определенные в среде.

Чтобы определить серверы формирования автономной адресной книги в среде без группы обеспечения доступности баз данных, используйте следующую команду:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,servername

изображение

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

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

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

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,database

изображение

Этап 2. Определите сервер почтовых ящиков, на котором установлена база данных с почтовым ящиком организации.

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

Get-MailboxDatabaseCopyStatus db1

изображение

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

Изменение сервера формирования автономной адресной книги

Сервер формирования автономной адресной книги можно изменить двумя способами.

Перемещение почтового ящика

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

Пример

DB1 — это база данных с единственной копией, которая установлена на сервере Exch1 и в которой размещен почтовый ящик организации. DB2 — это база данных почтовых ящиков на сервере Exch2.

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

Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2

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

Активация базы данных почтовых ящиков на другом сервере

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

Пример

Почтовый ящик организации размещен в базе данных DB1, копии которой находятся на серверах Exch1 и Exch2. В настоящее время база данных DB1 активна на сервере Exch1.

Чтобы активировать базу данных DB1 на сервере Exch2, сделав его тем самым сервером формирования автономной адресной книги, можно использовать следующую команду:

Move-ActiveMailboxDatabase DB1 -ActivateOnServer Exch2

Примечание. Перед изменением сервера формирования автономной адресной книги ознакомьтесь с рекомендациями в разделе "Размещение почтового ящика организации" ниже.

Создание почтового ящика организации

Администраторы могут создавать дополнительные почтовые ящики организации для обеспечения отказоустойчивости или обслуживания пользователей в географически распределенном развертывании Exchange.

Создание почтового ящика организации осуществляется в два этапа.

Этап 1. Создайте арбитражный почтовый ящик.

New-Mailbox -Arbitration -Name "OAB Краснодар" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName "Почтовый ящик автономной адресной книги для Краснодара"

Этап 2. Включите возможность OABGen.

Set-Mailbox -Arbitration oabs -OABGen $true

Примечание. Перед созданием дополнительных почтовых ящиков организации ознакомьтесь с рекомендациями в разделе "Размещение почтового ящика организации" ниже.

Изменение расписания формирования автономной адресной книги

В версиях, предшествовавших Exchange Server 2010, формирование автономной адресной книги выполнялось согласно расписанию, заданному в свойствах автономной адресной книги. При просмотре свойств автономной адресной книги в Exchange 2013 вы можете увидеть настроенное расписание. Однако формирование автономной адресной книги в Exchange Server 2013 осуществляется не в соответствии с расписанием, определенным в свойствах автономной адресной книги.

изображение

Вместо этого оно выполняется в соответствии со значениями свойств OABGeneratorWorkCycle и OABGeneratorWorkCycleCheckpoint, настроенными на сервере почтовых ящиков.

Пример

изображение

Значения на этом снимке экрана означают, что автономная адресная книга формируется один раз в день.

Какой сервер почтовых ящиков обработал запрос на загрузку автономной адресной книги?

Сервер клиентского доступа Exchange Server 2013 передает запрос на загрузку автономной адресной книги на соответствующий сервер почтовых ящиков. На сервере клиентского доступа ведется журнал всех обработанных запросов. Файлы журнала находятся в папке %ExchangeInstallPath%\Logging\HttpProxy\OAB\.

Эти файлы журнала — отличное средство для определения сервера почтовых ящиков, который сервер клиентского доступа выбрал для обработки запроса.

Ниже приведены сведения о некоторых важных полях в файлах журнала.

ПолеОписание
UrlStem Позволяет определить, какая автономная адресная книга была загружена и была ли загрузка полной или добавочной
AuthenticatedUser Имя пользователя, запросившего автономную адресную книгу
AnchorMailbox Отображаемое имя почтового ящика организации, который был определен как ближайший для обработки запроса на загрузку автономного почтового ящика
ServerHostName Имя сервера клиентского доступа, обработавшего запрос
HttpStatus Код состояния для действия прокси
ProxyAction Действие, которое сервер клиентского доступа выполнил для запроса; для автономной адресной книги Exchange 2013 чаще всего это будет действие прокси
TargetServer Имя сервера почтовых ящиков, на который был передан запрос

Для удобства чтения файл журнала можно импортировать в Excel.

Пример

изображение

Принудительное формирование автономной адресной книги

Формирование автономной адресной книги в Exchange Server 2013 можно запустить немедленно принудительным образом двумя способами.

Способ 1. Командлет Update-OfflineAddresBook

Приведенная ниже команда служит для принудительного формирования автономной адресной книги с именем "Автономная адресная книга по умолчанию" во всех почтовых ящиках организации.

Update-OfflineAddressBook "автономная адресная книга по умолчанию"

Примечание. Эта команда инициирует запрос RPC к каждому серверу почтовых ящиков, на котором размещен активный почтовый ящик организации.

Способ 2. Перезапуск службы помощника по обслуживанию почтовых ящиков

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

Размещение почтового ящика организации

Сервер клиентского доступа Exchange Server 2013 передает запрос на загрузку автономной адресной книги на ближайший сервер почтовых ящиков, на котором размещен активный почтовый ящик организации. Если в одном сайте Active Directory обнаружено несколько активных почтовых ящиков организации, запрос будет передаваться на все соответствующие серверы путем циклического перебора. Это может привести к слишком частым полным загрузкам автономной адресной книги.

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

Сценарии

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

Сценарий 1. Создание почтового ящика организации

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

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

Этап 1. Создание арбитражного почтового ящика

New-Mailbox -Arbitration -Name "OAB Краснодар" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName "Почтовый ящик автономной адресной книги для Краснодара"

Этап 2. Включение возможности OABGen для арбитражного почтового ящика

Set-Mailbox -Arbitration oabs -OABGen $true

Сценарий 2. Настройка расписания формирования автономной адресной книги

Вадим является администратором развертывания Exchange 2013 в компании Tail Spin Toys. Расписание формирования автономной адресной книги по умолчанию не устраивает компанию. Необходимо, чтобы формирование происходило каждый четвертый час.

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

Set-MailboxServer Exch1 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00

Через пару дней Вадим анализирует событие с кодом 17002 в журнале приложений, чтобы проверить, формируется ли автономная адресная книга каждые четыре часа.

изображение

Надеемся, эта статья помогла вам. Оставьте свой отзыв ниже.

Бхалчандра Атре (Bhalchandra Atre)

Это локализованная запись блога. Исходная статья находится по ссылке Managing OAB in Exchange Server 2013

]]> Средство устранения неполадок репликации общедоступных папок https://docs.microsoft.com/archive/blogs/exchange_ru/74 Thu, 31 Jan 2013 07:30:22 GMT https://blogs.technet.microsoft.com/exchange_ru/2013/01/31/74/ Исходная статья опубликована во вторник, 13 ноября 2012 г.

Недавно мы выпустили интерактивное пошаговое руководство по поиску и устранению неполадок репликации общедоступных папок в Microsoft Exchange 2003. Есть несколько способов получения доступа к средству устранения неполадок. Чтобы перейти к нему напрямую, можно воспользоваться этой ссылкой. Кроме того, ссылка будет встроена в различные статьи по теме репликации общедоступных папок, такие как следующая: https://support.microsoft.com/KB/842273.

Вы, наверное, задаетесь вопросом, зачем выпускать средство устранения неполадок для Exchange 2003, срок основной фазы поддержки которого уже истек. Мы приняли это решение по ряду причин. Во-первых, существует большое число наших клиентов, которые все еще не завершили переход с Exchange 2003, и мы хотели бы приложить все усилия, чтобы упростить их переход на более новые поддерживаемые версии продукта. Это лучший способ предоставления инструкций таким клиентам, так как для них больше недоступен вариант поддержки по телефону. Во-вторых, по большей части все проблемы с общедоступными папками Exchange Server 2003 уже определены, поэтому, создавая средство устранения неполадок для их решения, можно предположить, что в него не потребуется вносить существенные изменения. И наконец, учитывая тот факт, что механизм репликации общедоступных папок не сильно менялся в последнее время (до Exchange 2013), имеет смысл начать с Exchange 2003, так как на его основе мы сможем обновлять данные для более поздних версий.

Организация, предоставляющая поддержку, будет прилагать усилия по расширению этого средства устранения неполадок для включения версий 2007/2010 в будущем.

Это пошаговое руководство представляет собой набор инструкций по устранению неполадок репликации, как изложено в серии публикаций блога Билла Лонга (Bill Long) здесь, здесь и здесь. Целью средства является не замена всех данных, которые способствуют пониманию процесса репликации общедоступных папок, а скорее быстрый доступ к действиям, которые необходимо выполнить, чтобы выявить проблему (в случае возникновения проблем репликации).

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

Служба поддержки Exchange:

  • Ник Басиле (Nick Basile),
  • Роб Вейли (Rob Whaley),
  • Билл Лонг (Bill Long),
  • Шарлотта Реймундо (Charlotte Raymundo),
  • Уилл Дафф (Will Duff),
  • Нино Билич (Nino Bilic).

Рабочие группы по созданию документации и контента:

  • Бобби Дэфолт (Bobbie DeFault),
  • Джеффри Крисп (Geoffrey Crisp, Entirenet),
  • Джерри Ситсер (Jerry Sitser, Entiernet)
  • Джаррет Реншоу (Jarrett Renshaw),
  • Стар Ли (Star Li, Wicresoft),
  • Чень Цзян (Chen Jiang),
  • Виктор Чжан (Victor Zhang, Wicresoft).

С уважением,

Шарлотта Реймундо,
инженер по знаниям в области обмена сообщениями

Это локализованная запись блога. Исходная статья — Public Folder replication troubleshooter

]]>