Устранение ошибок доступности и доступности

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

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

Произошла ошибка при проверке безопасности сообщения

Проблема

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

Сбой автообнаружения для SMTP-адреса> адреса <электронной почты с ошибкой System.Web.Services.Protocols.SoapHeaderException: произошла ошибка при проверке безопасности сообщения в System.Web. Services.Protocols. SoapHttpClientProtocol. ReadResponse(SoapClientMessage message, WebResponse responseStream, Boolean asyncCall) в System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

Эта ошибка может возникнуть, если проверка подлинности WSSecurity не включена или требуется сбросить, либо после продления сертификатов федерации в Exchange Server.

Действия по устранению неполадок

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

1. Чтобы обновить метаданные в шлюзе федерации Майкрософт, выполните следующую команду два раза в локальной командной консоли Exchange (EMS):

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

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

2. Выполните следующие действия, чтобы переключить проверку подлинности WSSecurity:

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

      Примечания.

      • Выполните этот шаг, даже если выходные данные командлетов Get-AutodiscoverVirtualDirectoryGet-WebServicesVirtualDirectory PowerShell указывают на то, что проверка подлинности WSSecurity уже включена.

      • Эта процедура затрагивает только локальные подключения "свободная/занятая" и не влияет на другие подключения клиента и сервера.

   2. iisreset /noforce Выполните команду в PowerShell или окне командной строки на каждом локальном сервере Exchange Server, чтобы перезапустить СЛУЖБЫ IIS.

   3. Перезапустите все локальные серверы Exchange.

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

4. TargetSharingEpr Задайте значение параметра в связи организации с URL-адресом локальных внешних веб-служб Exchange (EWS), выполнив следующий командлет в Exchange Online PowerShell:

   Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
   

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

   Примечание. Значение параметра по умолчанию TargetSharingEpr пустое. Параметры TargetAutodiscoverEpr автообнаружения или DiscoveryEndpoint обычно содержат локальный внешний URL-адрес EWS (конечная точка автообнаружения). Чтобы получить TargetAutodiscoverEpr значения параметров и DiscoveryEndpoint , выполните следующие командлеты PowerShell:

   Get-OrganizationRelationship | FL TargetAutodiscoverEpr
   Get-IntraOrganizationConnector | FL DiscoveryEndpoint
   

5. Убедитесь, что TargetApplicationUri значение параметра в связи организации совпадает со значением AccountNamespace параметра в идентификаторе федеративной организации. Чтобы найти TargetApplicationUri значение параметра, выполните командлет PowerShell Test-OrganizationRelationship . Сведения о том, как AccountNamespace найти значение параметра, см. в разделе Demystifying hybrid free/busy.

К началу страницы

Не удалось выполнить веб-запрос прокси-сервера: не удалось подключиться к удаленному серверу

Проблема

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

Сбой веб-запроса прокси-сервера. , внутреннее исключение: System.Net.WebException: не удается подключиться к удаленному серверу; System.Net.Sockets.SocketException: попытка подключения завершилась сбоем из-за того, что подключенная сторона не ответила должным образом по истечении определенного периода времени или не удалось установить подключение, так как подключенный узел не смог ответить CUSTOMER_IP:443 / MICROSOFT_IP:443 в System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult).

Эта ошибка может возникнуть, если проблемы с сетевым подключением препятствуют входящим или исходящим подключениям между IP-адресами в Exchange Online и конечными точками в Exchange Server.

Действия по устранению неполадок

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

1. Убедитесь, что брандмауэр на каждом локальном сервере Exchange Server разрешает входящие или исходящие подключения между конечными точками Exchange Server и IP-адресами Exchange Online. Чтобы определить проблемы с брандмауэром, сделайте запрос на доступность из Exchange Online, а затем проверьте локальный брандмауэр, обратный прокси-сервер и сетевые журналы. Дополнительные сведения о настройке брандмауэра см. в статье Рекомендации по брандмауэру для федеративного делегирования , URL-адреса и диапазоны IP-адресов Microsoft 365.

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

   1. Создайте запрос на доступ к данным из Exchange Online.

   2. Проверьте журналы IIS в папке W3SVC1 для веб-сайта по умолчанию, чтобы убедиться, что запрос о доступности зарегистрирован. Путь к папке W3SVC1 — %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

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

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

3. Проверьте подключение из Exchange Online к локальной конечной точке веб-служб Exchange (EWS), выполнив следующий командлет в Exchange Online PowerShell:

   Test-MigrationServerAvailability -RemoteServer <on-premises mail server FQDN> -ExchangeRemoteMove -Credentials (Get-Credential)
   

   Примечания.

   • Этот тест полезен, если вы ограничиваете входящие подключения из Интернета, чтобы разрешить только IP-адресам Exchange Online подключаться к локальной конечной точке EWS.

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

   • При появлении запроса на ввод учетных данных введите учетные данные администратора домена в формате "домен\администратор".

К началу страницы

Сбой автообнаружения для адреса электронной почты: состояние HTTP 404

Проблема

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

Сбой автообнаружения для SMTP-адреса> пользователя адреса электронной почты <с ошибкой System.Net.WebException: сбой запроса с кодом 404 Not Foundсостояния HTTP .

Эта ошибка может возникнуть, если конечные точки автообнаружения нефункциональны или настроены неправильно.

Действия по устранению неполадок

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

1. Проверьте, допустима ли конечная точка автообнаружения:

   1. Выполните следующие команды, чтобы получить URL-адрес конечной точки автообнаружения из DiscoveryEndpoint параметра или TargetAutodiscoverEpr :

      Get-IntraOrganizationConnector | FL DiscoveryEndpoint
      Get-OrganizationRelationship | FL TargetAutodiscoverEpr
      

   2. Перейдите к URL-адресу конечной точки автообнаружения в веб-браузере. Допустимая конечная точка автообнаружения не возвращает код 404 Not Foundсостояния HTTP.

2. Убедитесь, что домен локального пользователя указан в параметрах организации (соединитель внутри организации или отношение организации) облачного пользователя:

   1. Выполните следующие командлеты PowerShell в Exchange Online PowerShell:

      Get-IntraOrganizationConnector | FL TargetAddressDomains
      Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
      

      Убедитесь, что домен локального пользователя указан в выходных данных любой команды. Например, если облачный пользователь user1@contoso.com ищет значение "свободная/занятость" для локального пользователя user2@contoso.ro, убедитесь, что локальный домен contoso.ro указан в списке.

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

      Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}
      

3. Убедитесь, что сопоставление обработчика SVC существует в виртуальных каталогах автообнаружения и EWS в разделе Веб-сайт по умолчанию в диспетчере IIS. Дополнительные сведения см. в разделе Не удалось получить сведения о федерации и возникло исключение целевым объектом.

   Примечание. Сопоставление AutodiscoverDiscoveryHander (*.svc) не используется для поиска доступности и доступности федерации.

К началу страницы

Сбой веб-запроса прокси-сервера исключений

LID: 43532

Проблема

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

Сбой веб-запроса прокси-сервера исключений. , внутреннее исключение: сбой запроса с состоянием HTTP 401: несанкционированная диагностика: 2000005; reason= "Пользователь, указанный контекстом пользователя в маркере, является неоднозначным". ; error_category="invalid_user"

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

Решение

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

1. Выполните поиск локальных объектов пользователей, имеющих дубликаты имени участника-пользователя, SMTP-адреса или SIP-адреса, с помощью пользовательских запросов LDAP. Запросы LDAP можно выполнять с помощью LDP.exe или оснастки MMC "Пользователи и компьютеры Active Directory".

   Например, чтобы показать всех пользователей, имеющих user@corp.contoso.com имя участника-пользователя, user@contoso.com в качестве SMTP-адреса или user@contoso.com SIP-адреса, используйте следующий запрос LDAP:

   (|(userPrincipalName=user@corp.contoso.com)(proxyAddresses=SMTP:user@contoso.com)(proxyAddresses=sip:user@contoso.com))
   

   Дополнительные сведения об использовании LDP.exe или пользователей и компьютеров Active Directory для поиска объектов Active Directory см. в разделе Примеры LDP.

2. Измените повторяющийся адрес или удалите повторяющийся объект пользователя.

К началу страницы

Удаленный хост принудительно разорвал существующее подключение

Проблема

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

Сбой веб-запроса прокси-сервера. , внутреннее исключение: System.Net.WebException: базовое подключение было закрыто: произошла непредвиденная ошибка при получении. System.IO.IOException: не удалось считывать данные из транспортного подключения. Существующее подключение было принудительно закрыто удаленным узлом. System.Net.Sockets.SocketException: существующее подключение было принудительно закрыто удаленным узлом.

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

Действия по устранению неполадок

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

1. Проверьте, попадают ли запросы на доступ к службам IIS на сервере Exchange Online. Создайте запрос доступности из Exchange Online и найдите следующие записи в журнале IIS, которые были сделаны во время запроса доступности и доступности:

   • Запись автообнаружения в папке %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover , которая содержит "ASAutoDiscover/CrossForest/EmailDomain".

     Примечание. Если вручную задать TargetSharingEpr параметр в связи организации для URL-адреса локальных внешних веб-служб Exchange (EWS), автообнаружения будет обходить стороной, и эта запись не будет существовать.

   • Запись EWS в папке %ExchangeInstallPath%\Logging\HttpProxy\Ews , которая содержит "ASProxy/CrossForest/EmailDomain".

   Примечание. Метки времени в журналах IIS используют время в формате UTC.

2. Убедитесь, что брандмауэр на каждом локальном сервере Exchange Server разрешает входящие или исходящие подключения между конечными точками Exchange Server и IP-адресами Exchange Online. Чтобы определить проблемы с брандмауэром, выполните запросы на доступность из Exchange Online, а затем проверьте локальный брандмауэр, обратный прокси-сервер и сетевые журналы. Дополнительные сведения о настройке брандмауэра см. в статье Рекомендации по брандмауэру для федеративного делегирования , URL-адреса и диапазоны IP-адресов Microsoft 365.

3. Если ваша организация использует отношения организации для реализации доступности , убедитесь, что на каждом сервере Exchange Server установлен сертификат федерации. Выполните следующие команды в командной консоли Exchange (EMS):

   Test-FederationTrustCertificate
   Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
   

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

4. Выполните следующие действия, чтобы переключить проверку подлинности WSSecurity:

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

   2. Перезапустите пулы приложений автообнаружения и EWS в диспетчере IIS.

   3. iisreset /noforce Выполните команду в PowerShell или окне командной строки на каждом локальном сервере Exchange Server, чтобы перезапустить СЛУЖБЫ IIS.

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

К началу страницы

Не удалось найти сведения о конфигурации для леса или домена в Active Directory

LID: 47932

Проблема

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

Не удалось найти сведения о конфигурации для домена> леса или домена <в Active Directory.

Эта ошибка может возникнуть, если параметры организации настроены неправильно.

Действия по устранению неполадок

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

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

   • Из облака в локальную среду

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

     1. Подключитесь к Exchange Online PowerShell, а затем выполните следующие командлеты PowerShell, чтобы получить федеративные домены:

        Get-IntraOrganizationConnector | FL TargetAddressDomains
        Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
        

        Убедитесь, что домен локального пользователя указан в выходных данных любой команды. Например, если облачный пользователь user1@contoso.com ищет значение "свободная/занятость" для локального пользователя user2@contoso.ro, убедитесь, что локальный домен contoso.ro указан в списке.

        Примечание.

        Доменные имена также можно найти, выполнив (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses в Exchange Online PowerShell или (Get-FederatedOrganizationIdentifier).Domains в локальной командной консоли Exchange (EMS).

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

        Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}​
        

   • Из локальной среды в облако

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

     1. В EMS выполните следующие командлеты PowerShell:

        Get-IntraOrganizationConnector | FL TargetAddressDomains
        Get-OrganizationRelationship -Identity <on-premises to cloud ID> | FL DomainNames
        

        Проверьте, соответствует ли домен пользователя облака одному из доменов, перечисленных в выходных данных команды. Например, если локальный пользователь user1@contoso.ro ищет сведения о доступности для облачного пользователя user2@contoso.com, убедитесь, что облачный домен contoso.com присутствует в выходных данных любой команды.

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

        Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<cloud domain>"}​
        

2. Убедитесь, что гибридное развертывание Exchange имеет полную гибридную конфигурацию. При необходимости повторно запустите мастер гибридной конфигурации (HCW) и выберите Полная гибридная конфигурация вместо минимальной гибридной конфигурации.Минимальная гибридная конфигурация не создает отношений организации (доверия федерации) или соединителей внутри организации.

К началу страницы

Сбой веб-запроса прокси-сервера: состояние HTTP 401

Проблема

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

Сообщение об ошибке 1

Сбой веб-запроса прокси-сервера. Внутреннее исключение: сбой запроса с состоянием HTTP 401: Неавторизовано.

Сообщение об ошибке 2

Сбой автообнаружения для адреса электронной почты. Внутреннее исключение: сбой запроса с состоянием HTTP 401: Неавторизовано.

Эта ошибка может возникнуть, если устройство периметра перед Exchange Server настроено для предварительной проверки подлинности (требуется имя пользователя и пароль) вместо передачи запросов из Exchange Online напрямую в Exchange Server. Виртуальные каталоги автообнаружения и EWS в гибридных развертываниях Exchange не поддерживают предварительную проверку подлинности.

Примерами устройств периметра являются обратные прокси-серверы, брандмауэры и шлюз управления угрозами Майкрософт (TMG).

Сообщение об ошибке 1 указывает, что запрос EWS завершился сбоем.

Сообщение об ошибке 2 указывает на сбой запроса автообнаружения.

Действия по устранению неполадок

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

1. Проверьте, включена ли предварительная проверка подлинности. Выполните следующие действия:

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

   2. Проверьте, достигает ли запрос на доступ к службам IIS из Exchange Online. Выполните запрос доступности и выполните поиск в журналах IIS в Exchange Server по любой из следующих записей во время запроса:

      • В папке %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover найдите запись автообнаружения с кодом 401 Unauthorized состояния HTTP и текстом ASAutoDiscover/CrossForest/EmailDomain.

        Примечание. Если TargetSharingEpr параметр в связи организации указывает локальный внешний URL-адрес EWS, то автообнаружение будет обходить стороной и эта запись не будет отображаться.

      • В папке %ExchangeInstallPath%\Logging\HttpProxy\Ews найдите запись EWS с кодом 401 Unauthorized состояния HTTP и текстом "ASProxy/CrossForest/EmailDomain".

      Примечание. Метки времени в журналах IIS используют время в формате UTC. Некоторые записи с кодом 401 Unauthorized состояния HTTP являются обычными.

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

2. Убедитесь, что вы включили WSSecurity (Exchange Server 2010) или проверку подлинности OAuth (Exchange Server 2013 и более поздних версий) в виртуальных каталогах EWS и автообнаружения. Кроме того, убедитесь, что вы включили параметры проверки подлинности по умолчанию в IIS для виртуальных каталогов автообнаружения и EWS. Дополнительные сведения см. в разделах Параметры проверки подлинности по умолчанию для виртуальных каталогов Exchange и Параметры по умолчанию для виртуальных каталогов Exchange.

3. Выполните действия, описанные в разделе Ошибка при проверке безопасности сообщения. Если WSSecurity настроена, убедитесь, что вы выполнили шаг, который переключает WSSecurity. Если проверка подлинности OAuth настроена вместо WSSecurity, переключите проверку подлинности OAuth в виртуальных каталогах автообнаружения и EWS, выполнив следующие команды:

   Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$False
   Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$True 
   Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$False 
   Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$True 
   

4. Убедитесь, что у вас есть актуальное доверие федерации. Выполните следующую команду в Exchange Online PowerShell , чтобы получить сведения о доверии федерации для организации Exchange:

   Get-FederationTrust
   

   Выходные данные команды должны содержать следующие сведения:

   Имя	ApplicationIdentifier	ApplicationUri
   WindowsLiveId	260563	outlook.com
   MicrosoftOnline	260563	outlook.com

   Примечание. Доверие WindowsLiveId — это экземпляр-получатель шлюза федерации Майкрософт. Доверие MicrosoftOnline — это бизнес-экземпляр шлюза федерации Майкрософт.

   Для актуального доверия федерации убедитесь, что ApplicationIdentifier параметр имеет 260563 значение , а не 292841, а ApplicationUri что — , outlook.com а не outlook.live.com. Если у вас устаревшее доверие федерации, обратитесь в службу поддержки Майкрософт.

К началу страницы

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

LID: 33676

Проблема

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

Сбой ответа от службы автообнаружения по адресу "https://Autodiscover/Autodiscover.svc/WSSecurity" из-за ошибки при настройке пользователя ExternalEwsUrl. Сообщение об ошибке: InvalidUser.

Сообщение об ошибке может появиться при выполнении теста "Свободный/занят" в анализаторе удаленного подключения.

Эта ошибка может возникнуть, если конечная точка облачного почтового ящика или автообнаружения настроена неправильно.

Действия по устранению неполадок

1. Убедитесь, что у пользователя облака есть дополнительный SMTP-адрес, включающий onmicrosoft.com домен, выполнив следующую команду:

   Get-Mailbox -Identity <mailbox ID> | FL EmailAddresses
   

   Например, у пользователя с основным SMTP-адресом user1@contoso.com должен быть дополнительный SMTP-адрес, аналогичный .user1@contoso.mail.onmicrosoft.com

   Если облачный пользователь управляется из Exchange Server, добавьте дополнительный SMTP-адрес в Exchange Server, а затем синхронизируйте данные удостоверений между локальной средой и идентификатором Microsoft Entra.

2. Выполните следующие команды, чтобы задать TargetSharingEpr значение параметра в связи организации с URL-адресом локальных внешних веб-служб Exchange (EWS):

   Connect-ExchangeOnline
   Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
   

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

К началу страницы

Вызывающий объект не имеет доступа к данным о доступности

LID: 47652, 44348, 40764

Проблема

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

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: вызывающий объект не имеет доступа к данным о доступности.

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

Действия по устранению неполадок

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

1. Проверьте разрешения календаря пользователя, у которого запрашивается информация о доступности, выполнив следующую команду:

   Get-MailboxFolderPermission -Identity <mailbox ID>:\Calendar
   

   Значение AccessRights пользователя Default в выходных данных команды должно иметь значение AvailabilityOnly или LimitedDetails. AccessRights Если значение равно None, выполните следующий командлет PowerShell, чтобы задать для этого значения значение AvailabilityOnly или LimitedDetails:

   Set-MailboxFolderPermission -Identity <mailbox ID>:\Calendar -AccessRights <access rights value>
   

2. Используйте применимый метод для проверки отношений организации:

   • Если облачному пользователю не удается просмотреть сведения о доступности для локального пользователя:

     Убедитесь, что отношение локальной организации указывает облачный домен, который может получить доступ к локальной информации о доступности. Примером облачного домена является contoso.mail.onmicrosoft.com. Сведения об изменении отношений организации в Exchange Server см. в статье Изменение отношений организации с помощью PowerShell. Также убедитесь, что адрес электронной почты от пользователя облака имеет тот же домен облака, например lucine.homsi@contoso.mail.onmicrosoft.com.

   • Если локальный пользователь не может просмотреть сведения о доступности для облачного пользователя:

     Убедитесь, что отношение облачной организации указывает локальный домен, который может получать доступ к сведениям о доступности и доступности облака. Примером локального домена является contoso.com. Сведения об изменении отношений организации в Exchange Online см. в статье Изменение отношений организации с помощью Exchange Online PowerShell. Кроме того, убедитесь, что адрес электронной почты от локального пользователя имеет тот же локальный домен, например lucine.homsi@contoso.com.

К началу страницы

Ошибка при обработке маркеров безопасности в сообщении

LID: 59916

Проблема

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

Ошибка ProxyWebRequestProcessingExceptionProxyRequestProcessingFailed
Сбой веб-запроса прокси-сервера. , внутреннее исключение: произошла ошибка при обработке маркеров безопасности в сообщении.

Эта ошибка может возникнуть, если сертификаты или метаданные в шлюзе федерации Майкрософт недопустимы.

Действия по устранению неполадок

1. Проверьте дату окончания срока действия и отпечатки сертификатов доверия локальной федерации, выполнив следующие командлеты PowerShell:

   Get-FederationTrust | FL
   Test-FederationTrust
   Test-FederationTrustCertificate
   

2. Чтобы обновить метаданные в шлюзе федерации Майкрософт, выполните следующую команду два раза в локальной командной консоли Exchange (EMS):

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Дополнительные сведения см. в статье Поиск по доступности перестает работать.

К началу страницы

Межорганиционный запрос не допускается, так как запрашивающий из другой организации

LID: 39660

Проблема

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

Межорганиционный запрос на SMTP-адрес> почтового ящика <не разрешен, так как запрашивающий из другой организации
Получатель: <SMTP-адрес>
Тип исключения: CrossOrganizationProxyNotAllowedForExternalOrganization
Сообщение об исключении. Межорганиционный запрос для <SMTP-адреса> не разрешен, так как запрашивающий из другой организации.

Например, пользователь lucine@adatum.com в клиенте, отличном от hybrid Exchange Online, не может просматривать сведения о доступности и доступности облачного пользователя chanok@contoso.com в гибридном клиенте. У пользователя chanok@contoso.com облака есть адрес chanok@contoso.mail.onmicrosoft.comэлектронной почты прокси-сервера . Клиент, не относясь к системе, имеет два организационных отношения: contoso.com (локальная среда) и contoso.mail.onmicrosoft.com (облако). Автообнаружения для contoso.com точек на Exchange Server и автообнаружения для contoso.mail.onmicrosoft.com точек на Exchange Online. При запросе сведений о доступности для пользователя в клиенте, отличном отhybrid chanok@contoso.com, появляется сообщение об ошибке, так как автообнаружение для contoso.com точек не указывает на Exchange Online.

Примечание.

Эквивалентный сценарий локальной гибридной сетки см. в разделе Гибридная сетка.

Обходной путь

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

• Пользователи в негибридном клиенте Exchange Online должны запрашивать сведения о доступности облачного пользователя в гибридном клиенте, используя адрес электронной почты, для которого автообнаружения указывает на Exchange Online. Например, lucine@adatum.com запрашивает сведения о доступности для chanok@contoso.mail.onmicrosoft.com. Чтобы успешно запрашивать сведения о доступности, пользователи в клиенте Exchange Online, отличном отhybrid, должны знать, какие пользователи в гибридном клиенте размещены в облаке, а для каждого из них — адрес электронной почты, для которого автообнаружения указывает на Exchange Online.

• Администратор клиента Exchange Online, не являющегосяhybrid, должен задать внешний адрес электронной почты каждого облачного пользователя в гибридном клиенте в качестве адреса электронной почты, для которого автообнаружения указывает на Exchange Online. Например, администратор в негибридном клиенте Exchange Online задает целевой адрес chanok@contoso.com электронной почты в гибридном клиенте значение chanok@contoso.mail.onmicrosoft.com. Чтобы внести это изменение, администратор должен знать, какие пользователи в гибридном клиенте размещены в облаке, а для каждого из них — адрес электронной почты, для которого автообнаружения указывает на Exchange Online. Дополнительные сведения о межтенантной синхронизации адресов электронной почты пользователей см. в статье Что такое межтенантная синхронизация.

Дополнительная информация

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

• Пользователь находится в клиенте Exchange Server, отличном отhybrid.
• Пользователь пытается просмотреть сведения о доступности локального пользователя в гибридном клиенте.
• Автообнаружение для гибридного клиента указывает на Exchange Online.

Например, пользователь в негибридном клиенте Exchange Server не может просматривать сведения о доступности локального пользователя chanok@contoso.com в гибридном клиенте, так как автообнаружатель указывает на contoso.com Exchange Online (autodiscover-s.outlook.com).

К началу страницы

Сбой запроса с состоянием HTTP 401: Unauthorized (отсутствует сертификат подписи)

Проблема

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

System.Net.WebException: сбой запроса с состоянием HTTP 401: Неавторизовано.

При выполнении командлета Test-OAuthConnectivity в выходных данных команды отображается следующее сообщение об ошибке:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: отсутствует сертификат подписи.

Например, выполните следующую команду:

Test-OAuthConnectivity -Service AutoD -TargetUri <on-premises Autodiscover URL> -Mailbox <mailbox ID> -Verbose | FL

Значение TargetUri параметра — URL-адрес локальной службы автообнаружения. Примером этого URL-адреса является https://mail.contoso.com/Autodiscover/Autodiscover.svc.

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

Решение

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

1. Выполните следующий командлет PowerShell в командной консоли Exchange (EMS), чтобы получить отпечаток сертификата OAuth, используемого конфигурацией проверки подлинности:

   Get-AuthConfig | FL CurrentCertificateThumbprint
   

   Если выходные данные команды не возвращают отпечаток сертификата, перейдите к шагу 3. В противном случае перейдите к следующему шагу.

2. Выполните следующий командлет PowerShell, чтобы проверить, существует ли сертификат, указанный на шаге 1, в Exchange Server:

   Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
   

   Если Exchange Server не возвращает сертификат, перейдите к шагу 3, чтобы создать новый сертификат.

   Если Exchange Server возвращает сертификат, но его отпечаток отличается от отпечатка, полученного на шаге 1, перейдите к шагу 4. На шаге 4 укажите отпечаток сертификата, возвращенного Exchange Server.

3. Выполните следующий командлет PowerShell, чтобы создать сертификат OAuth:

   New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "CN=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName <Domain> -Services SMTP
   

   Примечание.

   Если вам будет предложено заменить SMTP-сертификат, не принимайте этот запрос.

   На шаге 4 укажите отпечаток нового сертификата, созданного на этом шаге.

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

   $date=Get-Date 
   Set-AuthConfig -NewCertificateThumbprint <certificate thumbprint> -NewCertificateEffectiveDate $date
   Set-AuthConfig -PublishCertificate
   

   Примечание.

   Если вы получите предупреждение о том, что дата вступления в силу не превышает 48 часов, выберите продолжение.

5. Выполните следующий командлет PowerShell, чтобы удалить все ссылки на предыдущий сертификат:

   Set-AuthConfig -ClearPreviousCertificate
   

К началу страницы

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

Проблема

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

System.Web.Services.Protocols.SoapException: в приложении отсутствует связанная учетная запись для ролей RBAC, либо связанная учетная запись не имеет назначений ролей RBAC, либо учетная запись вызывающего пользователя отключена.

Действия по устранению неполадок

Чтобы устранить неполадки, упомянутые в сообщении об ошибке, выполните следующие действия. После выполнения шагов 1 и 2 проверьте, устранена ли проблема с доступностью.

1. Убедитесь, что запись "Exchange Online-ApplicationAccount" существует в списке партнерских приложений Exchange Server. Чтобы проверить это, выполните следующий командлет PowerShell в консоли управления Exchange (EMS):

   Get-PartnerApplication | FL LinkedAccount
   

   Запись учетной записи должна отображаться как <root domain FQDN>/Users/Exchange Online-ApplicationAccount. Если запись указана, перейдите к шагу 2.

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

   1. Выполните следующие командлеты PowerShell, чтобы найти учетную запись в локальной службе Active Directory:

      Set-ADServerSettings -ViewEntireForest $true 
      Get-User "Exchange Online-ApplicationAccount" 
      

      Если учетная запись указана в Active Directory, перейдите к шагу 1b.

      Если учетная запись не указана в Active Directory, возможно, она была удалена. Используйте ADRestore , чтобы проверить состояние учетной записи и восстановить ее, если она удалена. Если вы восстановили учетную запись с помощью ADRestore, перейдите к шагу 1b.

      Если вам не удается восстановить учетную запись с помощью ADRestore, выполните процедуру, описанную в статье Active Directory и домены для Exchange Server. Если эта процедура не восстанавливает учетную запись, вручную создайте учетную запись в Active Directory, а затем перейдите к шагу 1b.

   2. Выполните следующий командлет PowerShell, чтобы добавить учетную запись Active Directory в список партнерских приложений Exchange Server:

      Set-PartnerApplication "Exchange Online" -LinkedAccount "<root domain FQDN>/Users/Exchange Online-ApplicationAccount"
      

   3. Перезапустите все локальные серверы Exchange или iis, выполнив iisreset /noforce команду в PowerShell или окне командной строки на каждом сервере.

2. Выполните следующий командлет PowerShell в EMS, чтобы проверить назначения управления доступом на основе ролей (RBAC):

   Get-ManagementRoleAssignment -RoleAssignee "Exchange Online-ApplicationAccount" | FL Name,Role
   

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

   

3. Выполните поиск в следующих журналах на наличие проблем, указанных в сообщении об ошибке:

   • Журналы веб-служб Exchange (EWS), расположенные в папке %ExchangeInstallPath%\Logging\Ews
   • Журналы событий приложения
   • Журналы системных событий

4. Найдите в журналах, перечисленных на шаге 3, сообщение об ошибке, ссылающееся на AuthzInitializeContextFromSid. Если вы обнаружили это сообщение об ошибке, ознакомьтесь со следующими ресурсами:

   • Некоторым приложениям и API требуется доступ к сведениям об авторизации в объектах учетной записи.

   • Сбой проверок доступа из-за AuthZ

К началу страницы

Введенные и сохраненные пароли не совпадают.

Проблема

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

Получено исключение ошибки Soap. Введенные и сохраненные пароли не совпадают.

То же сообщение об ошибке отображается при выполнении следующего командлета, чтобы проверить, может ли пользователь облака получить маркер делегирования для локального почтового ящика пользователя:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Причина

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

Решение

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

1. Сброс пароля пользователя в облаке. Выберите тот же или другой пароль.

2. Обновите имя участника-пользователя (UPN) облачного пользователя, чтобы использовать onmicrosoft.com домен, а затем верните имя участника-пользователя к прежнему значению. Например, если имя участника-пользователя облака — user@contoso.com, измените его на временное имя участника-пользователя , user@contoso.mail.onmicrosoft.comа затем верните имя участника-пользователя на user@contoso.com. Для этого используйте Azure AD PowerShell или службу MSOL.

   • Использование Azure AD PowerShell

     Запустите такие командлеты PowerShell:

     Connect-AzureAD
     Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
     Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
     

   • Использование службы MSOL

     Запустите такие командлеты PowerShell:

     Connect-MsolService
     Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
     Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
     

3. Убедитесь, что ImmutableId значение локального объекта пользователя равно NULL. ImmutableId Проверьте значение локального объекта пользователя, выполнив следующую команду в командной консоли Exchange (EMS):

   Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
   

   В зависимости ImmutableId от значения используйте один из следующих методов.

   • Значение ImmutableId равно NULL.

     ImmutableId Если значение равно NULL, переключите его значение:

     1. ImmutableId Задайте для объекта удаленного почтового ящика имя участника-пользователя в облаке, выполнив следующий командлет PowerShell в EMS:

        Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
        

        Пример: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

     2. Синхронизируйте изменения в облако, выполнив следующие командлеты PowerShell в EMS:

        Import-Module ADSync
        Start-ADSyncSyncCycle -PolicyType Delta
        

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

        Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
        

     3. Верните ImmutableId объект удаленного почтового ящика в значение NULL, выполнив следующий командлет PowerShell в EMS:

        Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
        

     4. Синхронизируйте изменения с облаком, выполнив следующий командлет PowerShell в EMS:

        Start-ADSyncSyncCycle -PolicyType Delta
        

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

        Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
        

   • Значение ImmutableId не равно NULL

     ImmutableId Если значение не равно NULL, выполните следующую команду в EMS, чтобы задать ImmutableId значение NULL:

     Set-RemoteMailbox -Identity <user> -ImmutableId $null
     

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

     Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
     

К началу страницы

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

Проблема

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

Сообщение об ошибке 1

Срок действия пароля для учетной записи истек.

Сообщение об ошибке 2

Пароль должен быть изменен

То же сообщение об ошибке отображается при выполнении следующего командлета, чтобы проверить, может ли пользователь облака получить маркер делегирования для локального почтового ящика пользователя:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

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

Решение

Выберите решение, соответствующее сообщению об ошибке.

Решение для сообщения об ошибке 1

Чтобы устранить эту проблему, используйте Azure AD PowerShell или службу MSOL.

• Использование Azure AD PowerShell

  Запустите такие командлеты PowerShell:

  Connect-AzureAD
  Set-AzureADUser -ObjectId <account UPN> -PasswordPolicies DisablePasswordExpiration
  

• Использование службы MSOL

  Запустите такие командлеты PowerShell:

  Connect-MsolService
  Set-MsolUser -UserPrincipalName <account UPN> -PasswordNeverExpires $true
  

Решение для сообщения об ошибке 2

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

Connect-MsolService
Set-MsolUserPassword -UserPrincipalName <UPN> -ForceChangePassword $false

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

К началу страницы

Подготовка требуется для входа в федеративную учетную запись.

Проблема

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

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

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

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Эта ошибка может возникнуть, если в конфигурации федеративных пользователей в идентификаторе Microsoft Entra id возникла несогласованность.

Решение

Примечание.

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

Чтобы устранить эту проблему, обновите имя участника-пользователя (UPN) облачного пользователя, чтобы использовать onmicrosoft.com домен, а затем снова переключите его на прежнее значение (федеративный домен). Например, если имя участника-пользователя облака — user@contoso.com, переключите его на временное имя user@contoso.mail.onmicrosoft.com участника-пользователя, а затем снова на user@contoso.com. Для этого используйте один из следующих подходов (Azure AD PowerShell или служба MSOL):

• Использование Azure AD PowerShell

  Запустите такие командлеты PowerShell:

  Connect-AzureAD
  Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
  Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
  

• Использование службы MSOL

  Запустите такие командлеты PowerShell:

  Connect-MsolService
  Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
  Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
  

К началу страницы

Истекло время ожидания запроса

LID: 43404

Проблема

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

Истекло время ожидания запроса
Запрос не удалось обработать вовремя. Время ожидания запроса-завершения истекло.
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: запрос не удалось обработать вовремя. Время ожидания запроса-завершения истекло.
Имя сервера, на котором возникло исключение: <имя> сервера.

Вы также получите то же сообщение об ошибке при выполнении следующего командлета, чтобы проверить, может ли пользователь облака получить маркер делегирования для локального почтового ящика пользователя:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

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

Действия по устранению неполадок

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

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

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

   Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose
   Test-FederationTrust -UserIdentity <on-premises mailbox ID> -Verbose
   Test-FederationTrustCertificate
   

   Примечание. Выполните командлет Test-FederationTrust на всех локальных серверах Exchange.

3. Убедитесь, что Exchange Server имеет исходящий доступ в Интернет к обоим из следующих ресурсов:

   • Шлюз федерации Майкрософт (или сервер авторизации, если используется OAuth)

   • URL-адрес доступности для Microsoft 365: https://outlook.office365.com/ews/exchange.asmx

   Дополнительные сведения см. в разделах URL-адреса и диапазоны IP-адресов Microsoft 365 и Рекомендации по брандмауэру для федеративного делегирования.

4. Убедитесь, что системная учетная запись в Exchange Server имеет доступ к Интернету по следующим URL-адресам. Выполните следующие действия на каждом сервере Exchange.

   1. Выполните следующую команду PsExec , чтобы запустить сеанс PowerShell, который запускает веб-браузер из системной учетной записи:

      PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
      

   2. Проверьте доступ в браузере (без OAuth) из системной учетной записи к следующим URL-адресам шлюза федерации Майкрософт:

      • https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml

        В браузере должна отобразиться xml-страница.

      • https://login.microsoftonline.com/extSTS.srf

        В браузере появится запрос на скачивание файла.

      • https://domains.live.com/service/managedelegation2.asmx

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

   3. Проверьте доступ в браузере (OAuth) из системной учетной записи к следующим URL-адресам сервера авторизации Майкрософт:

      • https://outlook.office365.com/ews/exchange.asmx

        В браузере должно отобразиться запрос на вход.

      • https://login.windows.net/common/oauth2/authorize

        В браузере должна появиться ошибка входа: "Извините, но у нас возникли проблемы со входом".

      • https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2

        В браузере должен отобразиться код 400 Bad Requestсостояния HTTP или сообщение об ошибке входа " Извините, но у нас возникли проблемы со входом".

5. Получите сведения о запросе доступности, проверив журналы веб-служб Exchange (EWS):

   1. Создайте запрос на доступ к данным из Exchange Online.

   2. Найдите запись в журналах EWS и проверьте значение в столбце time-taken . Журналы EWS находятся в папке %ExchangeInstallPath%\Logging\Ews .

   3. Проверьте журналы IIS в папке W3SVC1 веб-сайта по умолчанию, чтобы убедиться, что запрос о доступности зарегистрирован. Путь к папке W3SVC1 — %SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

К началу страницы

Указанное имя элемента является недопустимым или пустым.

Проблема

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

S:Fault xmlns:S="http://www.w3.org/2003/05/soap-envelope"><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value>wst:FailedAuthentication</S:Value></S:Subcode></S:Code><S:Reason><S:Text xml:lang="en-US">Authentication Failure</S:Text></S:Reason><S:Detail><psf:error xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"><psf:value>0x80048821</psf:value><psf:internalerror><psf:code>0x80041034</psf:code><psf:text>Указанное имя элемента является недопустимым или пустым. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: получено исключение soap fault. в Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) в Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult)

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

• Несоответствие в идентификаторе Microsoft Entra для пользователей, запрашивающих маркер делегирования
• Несоответствие в конфигурации федеративных пользователей в службах федерации Active Directory (AD FS)

Действия по устранению неполадок

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

1. Обновите имя участника-пользователя (UPN) облачного пользователя, чтобы использовать onmicrosoft.com домен, а затем верните имя участника-пользователя к прежнему значению. Например, если имя участника-пользователя облака — user@contoso.com, измените его на временное имя участника-пользователя , user@contoso.mail.onmicrosoft.comа затем верните имя участника-пользователя на user@contoso.com. Для этого используйте один из следующих методов (Azure AD PowerShell или служба MSOL):

   • Использование Azure AD PowerShell

     Запустите такие командлеты PowerShell:

     Connect-AzureAD
     Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
     Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
     

   • Использование службы MSOL

     Запустите такие командлеты PowerShell:

     Connect-MsolService
     Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
     Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
     

2. Проверьте правила, конечные точки и журналы AD FS.

3. Найдите ошибку, связанную с пользователем ImmutableID облака, в выходных данных команды следующего командлета PowerShell:

   Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud user ID> -Verbose
   

   Например, выходные данные команды могут содержать следующее сообщение об ошибке:

   "Адрес электронной почты "XGuNpVunD0afQeVNfyoUIQ==" неправильный. Используйте следующий формат: имя пользователя, знак @, за которым следует доменное имя. Например, tonysmith@contoso.com или tony.smith@contoso.com.
   + CategoryInfo : NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

   Если появляется аналогичное сообщение об ошибке, используйте один из следующих методов, чтобы убедиться, что ImmutableId значение равно NULL (пустое значение):

   • Если облачный пользователь не синхронизирован из локальной среды, проверьте ImmutableId значение, выполнив следующий командлет PowerShell в Exchange Online PowerShell:

     Get-Mailbox -Identity <cloud mailbox> | FL ImmutableId
     

     ImmutableId Если значение не равно NULL, выполните следующий командлет PowerShell в Exchange Online PowerShell:

     Set-Mailbox -Identity <cloud mailbox> -ImmutableId $null
     

   • Если пользователь облака синхронизирован из локальной среды, проверьте ImmutableId значение для локального объекта пользователя, выполнив следующую команду в командной консоли Exchange (EMS):

     Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
     

     В зависимости ImmutableId от значения используйте один из следующих методов:

     • Значение ImmutableId равно NULL.

       ImmutableId Если значение равно NULL, переключите его значение:

       1. ImmutableId Задайте для объекта удаленного почтового ящика имя участника-пользователя в облаке, выполнив следующий командлет PowerShell в EMS:

          Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
          

          Пример: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

       2. Синхронизируйте изменения в облако, выполнив следующие командлеты PowerShell в EMS:

          Import-Module ADSync
          Start-ADSyncSyncCycle -PolicyType Delta
          

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

          Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
          

       3. Верните ImmutableId объект удаленного почтового ящика в значение NULL, выполнив следующий командлет PowerShell в EMS:

          Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
          

       4. Синхронизируйте изменения с облаком, выполнив следующий командлет PowerShell в EMS:

          Start-ADSyncSyncCycle -PolicyType Delta
          

          Убедитесь, что ImmutableId значение обновлено. Для этого выполните следующий командлет PowerShell в Exchange Online PowerShell:

          Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
          

     • Значение ImmutableId не равно NULL

       ImmutableId Если значение не равно NULL, выполните следующую команду в EMS, чтобы задать ImmutableId значение NULL:

       Set-RemoteMailbox -Identity <user> -ImmutableId $null
       

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

       Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
       

4. Проверьте параметры отношений с организацией. Дополнительные сведения см. в разделе Demystifying Hybrid Free/Busy.

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

   1. Запустите следующий командлет PowerShell:

      Test-FederationTrust -UserIdentity <on-premises user> -Verbose -Debug
      

   2. Повторно создайте доверие федерации. Дополнительные сведения см. в разделах Удаление доверия федерации и Настройка доверия федерации.

К началу страницы

Результирующий набор содержит слишком много записей календаря

LID: 54796

Проблема

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

Исключение. Результирующий набор содержит слишком много записей календаря. Допустимый размер = 1000; фактический размер = 5009.

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

Решение

Удалите некоторые элементы календаря из интервала времени, чтобы не превысить ограничение в 1000 элементов, которые можно получить в одном запросе о доступности.

Дополнительные сведения см. в разделе Невозможно просмотреть сведения о доступности в календаре другого пользователя в Exchange Online.

К началу страницы

Время начала рабочего времени должно быть меньше или равно времени окончания

Проблема

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

Исключение: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: время начала рабочего времени должно быть меньше или равно времени окончания.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

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

• WorkingHoursStartTime
• WorkingHoursEndTime
• WorkingHoursTimeZone

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

Решение

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

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

   Get-DistributionGroupMember -Identity <room list name> | Get-MailboxCalendarConfiguration | FL Identity,WorkingHours* 
   

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

   Set-MailboxCalendarConfiguration -Identity <room ID> -WorkingHoursStartTime <start time> -WorkingHoursEndTime <end time> -WorkingHoursTimeZone <time zone>
   

   Дополнительные сведения см. в разделе Set-MailboxCalendarConfiguration.

К началу страницы

Сбой запроса с состоянием HTTP 401: Неавторизован (маркер имеет недействимую подпись)

Проблема

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

System.Net.WebException: сбой запроса с состоянием HTTP 401: Неавторизовано.

При выполнении следующего командлета PowerShell для проверки подлинности OAuth:

Test-OAuthConnectivity -Service EWS -TargetUri <external EWS URL> -Mailbox <cloud mailbox ID> -Verbose | FL

Вы получите следующие выходные данные команды:

System.Net.WebException: The remote server returned an error: (401) Unauthorized. Boolean reloadConfig, diagnostics: 2000000; reason="The token has an invalid signature.";error_category="invalid_signature".

Примечание. Значение TargetUri параметра в команде Test-OAuthConnectivity является внешним URL-адресом веб-служб Exchange (EWS), например https://mail.contoso.com/ews/exchange.asmx.

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

Действия по устранению неполадок

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

1. Обновите метаданные авторизации на указанном сервере авторизации Майкрософт, который является доверенным для Exchange. Выполните следующий командлет PowerShell в EMS (локально):

   Set-AuthServer <name of the authorization server> -RefreshAuthMetadata 
   

   Подождите около 15 минут, чтобы команда вступила в силу полностью, или перезапустите IIS, выполнив iisreset /noforce команду в PowerShell или окне командной строки на каждом сервере Exchange Server.

2. Проверьте параметры сервера авторизации Майкрософт в организации Exchange, выполнив следующий командлет PowerShell в EMS:

   Get-AuthServer | FL Name, IssuerIdentifier, TokenIssuingEndpoint, AuthMetadataUrl, Enabled
   

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

   Name : WindowsAzureACS
   IssuerIdentifier : 00000001-0000-0000-c000-000000000000
   TokenIssuingEndpoint : https://accounts.accesscontrol.windows.net/XXXXXXXX-5045-4d00-a59a-c7896ef052a1/tokens/OAuth/2
   AuthMetadataUrl : https://accounts.accesscontrol.windows.net/contoso.com/metadata/json/1
   Enabled : True
   

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

К началу страницы

Сбой запроса с состоянием HTTP 401: Неавторизован (ключ не найден)

Проблема

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

System.Net.WebException: сбой запроса с состоянием HTTP 401: Неавторизовано.

При выполнении следующего командлета PowerShell в EMS для проверки проверки подлинности OAuth:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <on-premises mailbox ID> -Verbose | FL

Вы получите следующие выходные данные команды:

System.Net.WebException: удаленный сервер вернул ошибку: (401) Не авторизовано.
Ошибка: не удается получить маркер с сервера проверки подлинности. Код ошибки: "invalid_client". Описание: 'AADSTS70002:
Ошибка при проверке учетных данных. AADSTS50012: утверждение клиента содержит недопустимую подпись. [Причина — ключ не найден. Отпечаток ключа, используемого клиентом: "<отпечаток>".

Эта ошибка может возникнуть, если сертификат OAuth в Exchange Server не существует в Exchange Online.

Решение

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

1. Определите, существует ли локальный сертификат OAuth Exchange Server в организации Exchange Online:

   1. Выполните следующий командлет PowerShell в командной консоли Exchange (EMS), чтобы получить сертификат OAuth в Exchange Server:

      Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
      

      Выходные данные команды содержат Thumbprint значение .

   2. Выполните следующие командлеты PowerShell, чтобы получить сертификат OAuth Exchange Online с помощью службы MSOL:

      Connect-MsolService
      Get-MsolServicePrincipalCredential -ServicePrincipalName "00000002-0000-0ff1-ce00-000000000000" -ReturnKeyValues $true
      

      Value Если значение параметра в выходных данных команды пустое, сертификат OAuth не существует в Exchange Online. В этом случае перейдите к шагу 3, чтобы отправить локальный сертификат в Exchange Online.

      Value Если значение параметра не пустое, сохраните значение в файле с расширением ".cer". Откройте файл в средстве Microsoft Certificate Manager, чтобы просмотреть сертификат OAuth Exchange Online. Thumbprint Сравните значение сертификата Exchange Online с отпечатком локального сертификата, полученного на шаге 1a. Если значения отпечатка совпадают, перейдите к шагу 4. Если значения отпечатка не совпадают, выберите один из следующих параметров:

      • Перейдите к шагу 2, чтобы заменить существующий локальный сертификат сертификатом Exchange Online.

      • Перейдите к шагу 3, чтобы заменить существующий сертификат Exchange Online локальным сертификатом.

2. Замените существующий локальный сертификат сертификатом Exchange Online:

   1. Выполните следующий командлет PowerShell, чтобы обновить отпечаток локального сертификата:

      Set-AuthConfig -NewCertificateThumbprint <thumbprint of Exchange Online certificate> -NewCertificateEffectiveDate (Get-Date) 
      

      Если вы получите уведомление о том, что дата вступления сертификата в силу не превышает 48 часов, примите запрос на продолжение.

   2. Выполните следующий командлет PowerShell, чтобы опубликовать локальный сертификат:

      Set-AuthConfig -PublishCertificate  
      

   3. Выполните следующий командлет PowerShell, чтобы удалить все ссылки на предыдущий сертификат:

      Set-AuthConfig -ClearPreviousCertificate 
      

   4. Перейдите к шагу 4.

3. Экспортируйте локальный сертификат авторизации, а затем отправьте его в организацию Exchange Online.

4. Выполните следующий командлет PowerShell, чтобы проверить, является ли имя субъекта-службы в конфигурации локальной проверки подлинности :00000002-0000-0ff1-ce00-000000000000

   Get-AuthConfig | FL ServiceName
   

   Если значение имени субъекта-службы отличается, обновите имя субъекта-службы, выполнив следующий командлет PowerShell:

   Set-AuthConfig -ServiceName "00000002-0000-0ff1-ce00-000000000000"
   

К началу страницы

Сбой веб-запроса прокси-сервера: ответ не имеет правильного формата XML

Проблема

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

Сбой веб-запроса прокси-сервера. Внутреннее исключение: ответ не имеет правильного формата XML

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

Ответ, полученный от службы, не содержит допустимый XML-код.

Эти ошибки могут возникать по любой из следующих причин:

• Проблема с внешними веб-службами Exchange (EWS)
• Неправильная настройка сетевых устройств, таких как обратный прокси-сервер или брандмауэр

Действия по устранению неполадок

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

1. Проверьте, может ли запрос о доступности из Exchange Online получить доступ к СЛУЖБАм IIS на сервере Exchange Server. Выполните запрос доступности и выполните поиск в журналах IIS на наличие записей с кодом 200 OK состояния HTTP или 401 Unauthorized во время выполнения запроса. Эти записи указывают, что запрос доступности достиг IIS. Примечание. Метки времени в журналах IIS используют время в формате UTC.

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

2. Выполните запрос о доступности, а затем выполните поиск в журнале приложений Exchange Server в средстве просмотра событий Windows на наличие записей, которые были сделаны во время запроса, чтобы сузить причину проблемы.

К началу страницы

Не удается подключиться к удаленному серверу

Проблема

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

Не удалось связаться с https://login.microsoftonline.com/extSTS.srf., внутреннее исключение: не удается подключиться к удаленному серверу.

Эта ошибка может возникнуть, если одному или нескольким серверам Exchange не удается подключиться к URL-адресу шлюза федерации Майкрософт.

Действия по устранению неполадок

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

1. Выполните следующие командлеты PowerShell в командной консоли Exchange (EMS), чтобы проверить, можно ли получить маркер делегирования:

   Test-OrganizationRelationship -Identity "On-premises to O365*" -UserIdentity <on-premises user ID> -Verbose
   Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
   Test-FederationTrustCertificate
   

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

   • Шлюз федерации Майкрософт или сервер авторизации Майкрософт, если используется проверка подлинности OAuth.

   • URL-адрес доступности для Microsoft 365: https://outlook.office365.com/ews/exchange.asmx.

   Дополнительные сведения см. в разделах URL-адреса и диапазоны IP-адресов Microsoft 365 иРекомендации по брандмауэру для федеративного делегирования.

3. Убедитесь, что системная учетная запись в Exchange Server имеет доступ к Интернету по следующим URL-адресам. Выполните следующие действия на всех серверах Exchange в организации.

   1. Выполните следующую команду PsExec , чтобы запустить сеанс PowerShell, который запускает веб-браузер из системной учетной записи:

      PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
      

   2. Проверка доступа в браузере (без проверки подлинности OAuth) из системной учетной записи к следующим URL-адресам шлюза федерации Майкрософт:

      • https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml

        В браузере должна отобразиться xml-страница.

      • https://login.microsoftonline.com/extSTS.srf

        В браузере появится запрос на скачивание файла.

      • https://domains.live.com/service/managedelegation2.asmx

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

   3. Проверка доступа в браузере (проверка подлинности OAuth) из системной учетной записи к следующим URL-адресам сервера авторизации Майкрософт:

      • https://outlook.office365.com/ews/exchange.asmx

        В браузере должно отобразиться запрос на вход.

      • https://login.windows.net/common/oauth2/authorize

        В браузере должно появиться сообщение об ошибке входа: "Извините, но у нас возникли проблемы со входом".

      • https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2

        В браузере должен отобразиться код 400 Bad Request состояния HTTP или сообщение об ошибке входа: "Извините, но у нас возникли проблемы со входом".

К началу страницы

Сбой автообнаружения для адреса электронной почты: не удалось разрешить удаленное имя

Проблема

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

Сбой автообнаружения для адреса> электронной почты <пользователя с ошибкой System.Net.WebException: не удалось разрешить удаленное имя: "<локальное имя> узла".

Эта ошибка может возникнуть, если url-адрес локальной конечной точки автообнаружения или общедоступные параметры DNS неверны.

Действия по устранению неполадок

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

1. Выполните следующие командлеты PowerShell в Exchange Online PowerShell , чтобы получить значение TargetAutodiscoverEpr параметра:

   Get-IntraOrganizationConnector | FL TargetAutodiscoverEpr
   Get-OrganizationRelationship | FL TargetAutodiscoverEpr
   

   Например, если локальное имя узла в сообщении об ошибке имеет mail.contoso.comзначение , URL-адрес конечной точки автообнаружения, скорее всего, будет иметь значение https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

   TargetAutodiscoverEpr Если значение параметра правильное, перейдите к шагу 3. В противном случае перейдите к шагу 2.

2. Обновите URL-адрес конечной точки автообнаружения одним из следующих методов:

   • Запустите мастер гибридной конфигурации (HCW), чтобы восстановить конечную точку автообнаружения по умолчанию.

   • Вручную обновите DiscoveryEndpoint параметр или параметр, TargetAutodiscoverEpr выполнив один из следующих командлетов PowerShell:

     • Set-IntraOrganizationConnector -Identity <cloud connector ID> -DiscoveryEndpoint <Autodiscover endpoint URL>

     • Set-OrganizationRelationship <O365 to On-premises*> -TargetAutodiscoverEpr <Autodiscover endpoint URL>

3. Убедитесь, что имя локального узла в сообщении об ошибке (например, ) mail.contoso.comразрешается в общедоступной службе DNS. Запись DNS для имени узла должна указывать на локальную службу автообнаружения по URL-адресу конечной точки автообнаружения.

   Примечание. Если устранить проблему не удается и требуется временное решение, выполните один из следующих командлетов PowerShell, чтобы вручную обновить TargetSharingEpr значение параметра на URL-адрес внешних веб-служб Exchange (EWS). Внешний URL-адрес EWS должен выглядеть и https://<EWS hostname>/ews/exchange.asmx разрешаться в DNS.

   • Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>

   • Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>

   Примечание.

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

К началу страницы

Не удалось получить ASURL. Ошибка 8004010F

Проблема

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

Не удалось получить ASURL. Ошибка 8004010F.

Это общая ошибка, связанная со службой автообнаружения.

Действия по устранению неполадок

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

1. Убедитесь, что автообнаружатель для затронутого пользователя возвращает URL-адрес веб-служб Exchange (EWS) для пользователя.

2. Запустите тест автонастройки электронной почты в клиенте Outlook затронутого пользователя, чтобы убедиться, что автообнаружение возвращает URL-адрес EWS для пользователя.

3. Убедитесь, что доступность работает между локальными пользователями, размещенными на разных серверах Exchange.

4. Если у вас есть подсистемы балансировки нагрузки, проверьте, вызвана ли проблема с подсистемами балансировки нагрузки. Для этого измените файл "Узлы Windows" (на компьютере, на котором установлен клиент Outlook пользователя), чтобы обходить подсистемы балансировки нагрузки и указывать на конкретный сервер клиентского доступа.

5. Если между локальными пользователями работает режим "свободная или занятая", проверьте, имеют ли все локальные серверы Exchange исходящий доступ к URL-адресам и диапазонам IP-адресов Microsoft 365.

6. Проверьте, может ли каждый сервер Exchange Server получить маркер делегирования. Для этого выполните следующий командлет PowerShell в EMS на всех локальных серверах Exchange:

   Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
   

   Если команде не удается получить маркер делегирования, проверьте, может ли сервер подключаться к Office 365 на уровне прокси-сервера или брандмауэра.

К началу страницы

Сбой веб-запроса прокси-сервера: объект перемещен

Проблема

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

Сбой веб-запроса прокси-сервера. , внутреннее исключение: System.Net.WebException: сбой запроса с сообщением об ошибке: Объект перемещен.

Эта ошибка может возникнуть, TargetSharingEpr если для параметра в параметрах организации задан неправильный URL-адрес конечной точки веб-служб Exchange (EWS).

Чтобы получить TargetSharingEpr значение параметра из параметров организации (соединитель внутри организации или отношение организации), можно выполнить следующие командлеты PowerShell:

Get-IntraOrganizationConnector | FL TargetSharingEpr
Get-OrganizationRelationship | FL TargetSharingEpr

Убедитесь, что TargetSharingEpr значение параметра не разрешается в общедоступной службе DNS.

Примечание. Мастер гибридной конфигурации (HCW) не задает значение параметра, TargetSharingEpr если вы не выберете Использовать современную гибридную технологию Exchange для установки гибридного агента. В этом сценарии HCW задает TargetSharingEpr для параметра значение внешней конечной точки URL-адреса EWS, похожее на https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmx. Вы также можете задать TargetSharingEpr значение параметра вручную. TargetSharingEpr Если задано значение конечной точки, Outlook обходит автообнаружения и подключается непосредственно к этой конечной точке.

Решение

Чтобы устранить эту проблему, выполните следующую команду, чтобы вручную обновить TargetSharingEpr значение параметра на внешний URL-адрес EWS, который разрешается в DNS:

• Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>
• Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>

К началу страницы

Запрос прерван: не удалось создать безопасный канал SSL/TLS

Проблема

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

Запрос прерван: не удалось создать безопасный канал SSL/TLS.

Причина 1. Пользователь облака не может просматривать сведения о доступности для локального пользователя

Эта проблема может возникнуть, если протокол TLS 1.2 неправильно настроен или отключен в локальной конечной точке, к которому подключается Microsoft 365, например Exchange Server или брандмауэре.

Причина 2. Локальный пользователь не может просматривать сведения о доступности для облачного пользователя

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

• Сертификат Microsoft 365 (outlook.office365.com) отсутствует в хранилище доверенных корневых центров сертификации (ЦС).
• Существует несоответствие набора шифров .
• Другие проблемы SSL/TLS.

Действия по устранению неполадок

Используйте следующие средства для диагностики локальных проблем с TLS 1.2:

• Запустите тест SSL-сервера в анализаторе удаленного подключения Майкрософт.
• Запустите скрипт HealthChecker в командной консоли Exchange (EMS) на каждом сервере Exchange.

Сведения о конфигурации TLS см. в разделах Рекомендации по настройке TLS Exchange Server и Подготовка к TLS 1.2.

Сведения о том, как проверить наличие сертификатов в доверенном корневом хранилище ЦС, см. в разделе Просмотр сертификатов с помощью оснастки MMC.

Сведения о поддерживаемых наборах шифров TLS см. в статье Наборы шифров TLS, поддерживаемые Microsoft 365.

К началу страницы

Пользователь, указанный контекстом пользователя в маркере, не существует

Проблема

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

Пользователь, указанный контекстом пользователя в маркере, не существует. error_category="invalid_user". 401: не авторизовано.

То же сообщение об ошибке появляется при выполнении командлета PowerShell Test-OAuthConnectivity .

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

Решение

Чтобы устранить эту проблему, используйте Microsoft Entra Connect для синхронизации локального пользователя и соответствующего объекта mail-user в идентификаторе Microsoft Entra.

К началу страницы

Недопустимый компонент hostname в утверждении аудитории

Проблема

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

Компонент hostname утверждения аудитории "https://< hybrid.domain.com>" недопустим; error_category="invalid_resource"

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

Причина 1

Разгрузка SSL и проверка подлинности OAuth включены. Разгрузка SSL не работает, если включена проверка подлинности OAuth.

Причина 2

Сетевое устройство перед Exchange Server блокирует запросы о доступности.

Решение

Обходной путь для причины 1

Выберите одно из следующих обходных решений:

• Отключите разгрузку SSL для веб-служб Exchange (EWS) и автообнаружения в локальной среде. Дополнительные сведения см. в разделах Настройка разгрузки SSL для автообнаружения и Настройка разгрузки SSL для EWS и параметры SSL по умолчанию.

• Выполните следующий командлет PowerShell, чтобы отключить проверку подлинности OAuth, отключив соединитель внутри облачной организации:

  Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
  

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

  Get-OrganizationRelationship
  

  Дополнительные сведения о параметрах отношений организации см. в разделе Demystifying Hybrid Free/Busy.

Решение для причины 2

Настройте сетевое устройство перед Exchange, чтобы не блокировать запросы о доступности.

К началу страницы

Сбой веб-запроса прокси-сервера с состоянием HTTP 503: служба недоступна

Проблема

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

Сбой веб-запроса прокси-сервера, внутреннее исключение: System.Net.WebException: сбой запроса с состоянием HTTP 503: служба недоступна...

Эта ошибка может возникнуть, если остановлена служба Microsoft Windows, серверный компонент, пул приложений IIS или неправильно настроенная конечная точка.

Действия по устранению неполадок

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

1. Убедитесь, что службы Windows, необходимые Exchange Server, запущены. Чтобы проверить состояние служб, выполните следующий командлет PowerShell на каждом сервере Exchange в организации:

   Test-ServiceHealth
   

   Используйте консоль служб, чтобы запустить все остановленные службы, необходимые для Exchange Server.

2. Убедитесь, что необходимые компоненты Exchange Server активны. Чтобы проверить состояние компонентов, выполните следующий командлет PowerShell на каждом сервере Exchange в организации:

   Get-ServerComponentState <server name>
   

   Чтобы активировать неактивный компонент, используйте командлет PowerShell Set-ServerComponentState .

3. Убедитесь, что запущены следующие пулы приложений IIS для веб-служб Exchange (EWS) и автообнаружения:

   • MSExchangeServicesAppPool
   • MSExchangeSyncAppPool
   • MSExchangeAutodiscoverAppPool

4. Проверьте, допустима ли конечная точка автообнаружения. Выполните следующие действия:

   1. Выполните следующие командлеты PowerShell, чтобы получить URL-адрес конечной точки автообнаружения из значений DiscoveryEndpoint параметра или TargetAutodiscoverEpr :

      Get-IntraOrganizationConnector | FL DiscoveryEndpoint
      Get-OrganizationRelationship | FL TargetAutodiscoverEpr
      

   2. Перейдите по URL-адресу конечной точки автообнаружения в веб-браузере или выполните Invoke-WebRequest -Uri "<endpoint URL>" -Verbose командлет PowerShell, чтобы убедиться, что URL-адрес действителен. Желательно проверить URL-адрес из внешней сети.

5. Проверьте, является ли URL-адрес EWS допустимым, выполнив следующие действия.

   1. Выполните следующие командлеты PowerShell, чтобы получить URL-адрес EWS из TargetSharingEpr значения параметра в параметрах организации:

      Get-IntraOrganizationConnector | FL TargetSharingEpr
      Get-OrganizationRelationship | FL TargetSharingEpr
      

   Б. Перейдите по URL-адресу EWS в веб-браузере или выполните Invoke-WebRequest -Uri "<endpoint URL>" -Verbose командлет PowerShell, чтобы убедиться, что URL-адрес является допустимым. Желательно проверить URL-адрес из внешней сети.

6. Проверьте журналы IIS на наличие запросов доступности, возвращающих код 503 Service Unavailableсостояния HTTP:

   1. Создайте запрос на доступ к данным из Exchange Online.

   2. Проверьте наличие записей кода 503 Service Unavailable состояния HTTP в журналах IIS в папке W3SVC1 для веб-сайта по умолчанию на каждом сервере Exchange Server. Путь к папке W3SVC1 — %SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Эти записи помогут определить сервер, на который возникла проблема.

   3. Если запрос доступности не зарегистрирован в папке W3SVC1 , проверьте, зарегистрирован ли запрос в журналах ошибок в папке HTTPERR на каждом сервере Exchange. Путь к папке HTTPERR — %SystemRoot%\System32\LogFiles\HTTPERR. Если запрос доступности регистрируется в журналах HTTPERR , проверьте наличие неправильно настроенных параметров IIS.

7. Проверьте заголовок ответа сервера, который вы получаете при подключении к локальному URL-адресу EWS, чтобы убедиться, что IIS (не другой веб-сервер) отправил ответ. Для этого выполните следующие команды в сеансе PowerShell, который не подключен к локальной системе EWS (не выполняйте команды в командной консоли Exchange):

   $req = [System.Net.HttpWebRequest]::Create("<EWS URL>") 
   $req.UseDefaultCredentials = $false $req.GetResponse()
   $ex = $error[0].Exception
   $ex.InnerException.Response $resp.Headers["Server"]
   

   Например, если в выходных данных команды отображается "Microsoft-HTTPAPI/2.0" вместо "Microsoft -IIS/10.0", скорее всего, служба прокси веб-приложения (WAP) (не IIS) ответила на запрос. Проверьте, не отключена ли служба WAP.

К началу страницы

Сбой веб-запроса прокси-сервера с состоянием HTTP 504: истечение времени ожидания шлюза

LID: 43532

Проблема

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

Сбой веб-запроса прокси-сервера, внутреннее исключение: сбой запроса с состоянием HTTP 504: время ожидания шлюза...

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

Решение

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

1. TargetSharingEpr Проверьте значение параметра в параметрах организации. Значение должно выглядеть так: https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx. Чтобы определить значение TargetSharingEpr параметра, выполните следующие командлеты PowerShell:

   Get-IntraOrganizationConnector | FL TargetSharingEpr
   Get-OrganizationRelationship | FL TargetSharingEpr
   

   TargetSharingEpr Если значение параметра неверно:

   1. Запустите мастер гибридной конфигурации (HCW) и выберите Использовать классическую гибридную топологию Exchange.

   2. Повторно запустите HCW и выберите Использовать современную гибридную топологию Exchange. Эта процедура заставляет HCW сбросить TargetSharingEpr значение параметра.

2. Проверьте состояние гибридной службы Microsoft на сервере, где установлен гибридный агент. Если служба остановлена, запустите ее.

3. Проверьте состояние гибридного агента. Если состояние неактивно:

   1. Запустите мастер гибридной конфигурации (HCW) и выберите Использовать классическую гибридную топологию Exchange.

   2. Повторно запустите HCW и выберите Использовать современную гибридную топологию Exchange. Эта процедура заставляет HCW переустановить гибридный агент.

   3. Установите модуль PowerShell гибридного агента, а затем выполните командлет PowerShell Get-HybridApplication , чтобы найти внутренний URL-адрес, на который указывает гибридный агент.

4. Перейдите к внутреннему URL-адресу, который вы нашли на шаге 3. Устраните все обнаруживаемые ошибки, например ошибки сертификатов.

5. Настройте гибридный агент для направления запросов к подсистеме балансировки нагрузки , а не к серверу под управлением Microsoft Exchange Server, чтобы исключить проблемы, которые могут возникнуть на этом сервере.

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

К началу страницы