Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Чтобы устранить ошибку, связанную с сведениями о доступности, выберите соответствующее сообщение об ошибке в оглавлении в верхней части этой статьи.
Если действия по устранению неполадок не помогли устранить проблему, обратитесь в службу поддержки Майкрософт.
Произошла ошибка при проверке безопасности сообщения
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя. При диагностике проблемы отображается следующее сообщение об ошибке:
Сбой автообнаружения для 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.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Чтобы обновить метаданные в шлюзе федерации Майкрософт, выполните следующую команду два раза в локальной командной консоли Exchange (EMS):
Get-FederationTrust | Set-FederationTrust -RefreshMetadata
Дополнительные сведения см. в статье Поиск по доступности перестает работать в локальной среде или гибридном развертывании Exchange Server.
Выполните следующие действия, чтобы переключить проверку подлинности WSSecurity:
Выполните процедуру , описанную в статье Пользователи из федеративной организации не могут видеть сведения о доступности другой организации Exchange , чтобы включить или сбросить проверку подлинности WSSecurity в виртуальных каталогах автообнаружения и EWS на всех локальных серверах Exchange.
Примечания.
Выполните этот шаг, даже если выходные данные командлетов
Get-AutodiscoverVirtualDirectory
Get-WebServicesVirtualDirectory
PowerShell указывают на то, что проверка подлинности WSSecurity уже включена.Эта процедура затрагивает только локальные подключения "свободная/занятая" и не влияет на другие подключения клиента и сервера.
iisreset /noforce
Выполните команду в PowerShell или окне командной строки на каждом локальном сервере Exchange Server, чтобы перезапустить СЛУЖБЫ IIS.Перезапустите все локальные серверы Exchange.
Проверьте и устраните все предупреждения или ошибки, связанные с временными отклонениями, в журнале системных событий.
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
Убедитесь, что
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.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Убедитесь, что брандмауэр на каждом локальном сервере Exchange Server разрешает входящие или исходящие подключения между конечными точками Exchange Server и IP-адресами Exchange Online. Чтобы определить проблемы с брандмауэром, сделайте запрос на доступность из Exchange Online, а затем проверьте локальный брандмауэр, обратный прокси-сервер и сетевые журналы. Дополнительные сведения о настройке брандмауэра см. в статье Рекомендации по брандмауэру для федеративного делегирования , URL-адреса и диапазоны IP-адресов Microsoft 365.
Убедитесь, что запросы из Exchange Online достигают локальных серверов клиентского доступа. Выполните следующие действия на всех локальных серверах клиентского доступа.
Создайте запрос на доступ к данным из Exchange Online.
Проверьте журналы IIS в папке W3SVC1 для веб-сайта по умолчанию, чтобы убедиться, что запрос о доступности зарегистрирован. Путь к папке W3SVC1 —
%SystemDrive%\inetpub\logs\LogFiles\W3SVC1
.Проверьте журналы прокси-сервера HTTP в следующих папках, чтобы убедиться, что запрос о доступности зарегистрирован:
%ExchangeInstallPath%\Logging\HttpProxy\Autodiscover
%ExchangeInstallPath%\Logging\HttpProxy\Ews
Проверьте подключение из 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 .
Эта ошибка может возникнуть, если конечные точки автообнаружения нефункциональны или настроены неправильно.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Проверьте, допустима ли конечная точка автообнаружения:
Выполните следующие команды, чтобы получить URL-адрес конечной точки автообнаружения из
DiscoveryEndpoint
параметра илиTargetAutodiscoverEpr
:Get-IntraOrganizationConnector | FL DiscoveryEndpoint Get-OrganizationRelationship | FL TargetAutodiscoverEpr
Перейдите к URL-адресу конечной точки автообнаружения в веб-браузере. Допустимая конечная точка автообнаружения не возвращает код
404 Not Found
состояния HTTP.
Убедитесь, что домен локального пользователя указан в параметрах организации (соединитель внутри организации или отношение организации) облачного пользователя:
Выполните следующие командлеты 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
указан в списке.Если домен локального пользователя не существует в параметрах организации облачного пользователя, добавьте домен, выполнив следующий командлет PowerShell:
Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}
Убедитесь, что сопоставление обработчика SVC существует в виртуальных каталогах автообнаружения и EWS в разделе Веб-сайт по умолчанию в диспетчере IIS. Дополнительные сведения см. в разделе Не удалось получить сведения о федерации и возникло исключение целевым объектом.
Примечание. Сопоставление
AutodiscoverDiscoveryHander
(*.svc) не используется для поиска доступности и доступности федерации.
Сбой веб-запроса прокси-сервера исключений
LID: 43532
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя. При диагностике проблемы отображается следующее сообщение об ошибке:
Сбой веб-запроса прокси-сервера исключений. , внутреннее исключение: сбой запроса с состоянием HTTP 401: несанкционированная диагностика: 2000005; reason= "Пользователь, указанный контекстом пользователя в маркере, является неоднозначным". ; error_category="invalid_user"
Эта ошибка может возникнуть, если имя участника-пользователя, SMTP-адрес или SIP-адрес локального пользователя используется другим локальным почтовым ящиком.
Решение
Для устранения данной проблемы выполните следующие действия:
Выполните поиск локальных объектов пользователей, имеющих дубликаты имени участника-пользователя, 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.
Измените повторяющийся адрес или удалите повторяющийся объект пользователя.
Удаленный хост принудительно разорвал существующее подключение
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя. При диагностике проблемы отображается следующее сообщение об ошибке:
Сбой веб-запроса прокси-сервера. , внутреннее исключение: System.Net.WebException: базовое подключение было закрыто: произошла непредвиденная ошибка при получении. System.IO.IOException: не удалось считывать данные из транспортного подключения. Существующее подключение было принудительно закрыто удаленным узлом. System.Net.Sockets.SocketException: существующее подключение было принудительно закрыто удаленным узлом.
Эта ошибка может возникнуть, если локальный брандмауэр блокирует входящее подключение с внешнего исходящего IP-адреса в Exchange Online.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Проверьте, попадают ли запросы на доступ к службам 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.
Убедитесь, что брандмауэр на каждом локальном сервере Exchange Server разрешает входящие или исходящие подключения между конечными точками Exchange Server и IP-адресами Exchange Online. Чтобы определить проблемы с брандмауэром, выполните запросы на доступность из Exchange Online, а затем проверьте локальный брандмауэр, обратный прокси-сервер и сетевые журналы. Дополнительные сведения о настройке брандмауэра см. в статье Рекомендации по брандмауэру для федеративного делегирования , URL-адреса и диапазоны IP-адресов Microsoft 365.
Если ваша организация использует отношения организации для реализации доступности , убедитесь, что на каждом сервере Exchange Server установлен сертификат федерации. Выполните следующие команды в командной консоли Exchange (EMS):
Test-FederationTrustCertificate Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
Если сертификат федерации установлен, выходные данные команды не должны содержать никаких ошибок или предупреждений.
Выполните следующие действия, чтобы переключить проверку подлинности WSSecurity:
Выполните процедуру , описанную в статье Пользователи из федеративной организации не могут видеть сведения о доступности другой организации Exchange , чтобы включить или сбросить проверку подлинности WSSecurity в виртуальных каталогах автообнаружения и EWS на всех локальных серверах Exchange. Выполните этот шаг, даже если проверка подлинности WSSecurity уже включена.
Перезапустите пулы приложений автообнаружения и EWS в диспетчере IIS.
iisreset /noforce
Выполните команду в PowerShell или окне командной строки на каждом локальном сервере Exchange Server, чтобы перезапустить СЛУЖБЫ IIS.
Если эта проблема затрагивает только несколько облачных пользователей, а их почтовые ящики размещены на одном почтовом сервере в Exchange Online, проверьте, может ли этот почтовый сервер подключаться к локальным конечным точкам. Возможно, локальная конечная точка блокирует подключения с исходящего IP-адреса этого почтового сервера.
Не удалось найти сведения о конфигурации для леса или домена в Active Directory
LID: 47932
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя или наоборот. При диагностике проблемы отображается следующее сообщение об ошибке:
Не удалось найти сведения о конфигурации для домена> леса или домена <в Active Directory.
Эта ошибка может возникнуть, если параметры организации настроены неправильно.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Убедитесь, что домен пользователя, у которого запрашиваются сведения о доступности, существует в параметрах организации пользователя, который пытается просмотреть сведения о доступности. Выберите одну из следующих процедур в зависимости от направления доступности.
Из облака в локальную среду
Для пользователя облака, который пытается просмотреть сведения о доступности для локального пользователя, выполните следующие действия.
Подключитесь к 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).Если домен локального пользователя не существует в параметрах организации облачного пользователя, добавьте домен, выполнив следующий командлет PowerShell:
Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}
Из локальной среды в облако
Для локального пользователя, который пытается просмотреть сведения о доступности для облачного пользователя, выполните следующие действия.
В EMS выполните следующие командлеты PowerShell:
Get-IntraOrganizationConnector | FL TargetAddressDomains Get-OrganizationRelationship -Identity <on-premises to cloud ID> | FL DomainNames
Проверьте, соответствует ли домен пользователя облака одному из доменов, перечисленных в выходных данных команды. Например, если локальный пользователь
user1@contoso.ro
ищет сведения о доступности для облачного пользователяuser2@contoso.com
, убедитесь, что облачный доменcontoso.com
присутствует в выходных данных любой команды.Если домен пользователя облака не существует в параметрах организации локального пользователя, добавьте домен. Выполните следующую команду:
Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<cloud domain>"}
Убедитесь, что гибридное развертывание Exchange имеет полную гибридную конфигурацию. При необходимости повторно запустите мастер гибридной конфигурации (HCW) и выберите Полная гибридная конфигурация вместо минимальной гибридной конфигурации.Минимальная гибридная конфигурация не создает отношений организации (доверия федерации) или соединителей внутри организации.
Сбой веб-запроса прокси-сервера: состояние HTTP 401
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя. При диагностике проблемы вы обнаружите одно из следующих сообщений об ошибке.
Сообщение об ошибке 1
Сбой веб-запроса прокси-сервера. Внутреннее исключение: сбой запроса с состоянием HTTP 401: Неавторизовано.
Сообщение об ошибке 2
Сбой автообнаружения для адреса электронной почты. Внутреннее исключение: сбой запроса с состоянием HTTP 401: Неавторизовано.
Эта ошибка может возникнуть, если устройство периметра перед Exchange Server настроено для предварительной проверки подлинности (требуется имя пользователя и пароль) вместо передачи запросов из Exchange Online напрямую в Exchange Server. Виртуальные каталоги автообнаружения и EWS в гибридных развертываниях Exchange не поддерживают предварительную проверку подлинности.
Примерами устройств периметра являются обратные прокси-серверы, брандмауэры и шлюз управления угрозами Майкрософт (TMG).
Сообщение об ошибке 1 указывает, что запрос EWS завершился сбоем.
Сообщение об ошибке 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 и обычно исключает проблемы с предварительной проверки подлинности. Если указанные записи не находятся, проверьте журналы обратного прокси-сервера и брандмауэра, чтобы понять, где завис запрос на доступность.
Убедитесь, что вы включили WSSecurity (Exchange Server 2010) или проверку подлинности OAuth (Exchange Server 2013 и более поздних версий) в виртуальных каталогах EWS и автообнаружения. Кроме того, убедитесь, что вы включили параметры проверки подлинности по умолчанию в IIS для виртуальных каталогов автообнаружения и EWS. Дополнительные сведения см. в разделах Параметры проверки подлинности по умолчанию для виртуальных каталогов Exchange и Параметры по умолчанию для виртуальных каталогов Exchange.
Выполните действия, описанные в разделе Ошибка при проверке безопасности сообщения. Если 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
Убедитесь, что у вас есть актуальное доверие федерации. Выполните следующую команду в 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.
Сообщение об ошибке может появиться при выполнении теста "Свободный/занят" в анализаторе удаленного подключения.
Эта ошибка может возникнуть, если конечная точка облачного почтового ящика или автообнаружения настроена неправильно.
Действия по устранению неполадок
Убедитесь, что у пользователя облака есть дополнительный 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.
Выполните следующие команды, чтобы задать
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: вызывающий объект не имеет доступа к данным о доступности.
Эта ошибка может возникнуть, если почтовый ящик пользователя, у которого запрашиваются сведения о доступности, настроен неправильно.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Проверьте разрешения календаря пользователя, у которого запрашивается информация о доступности, выполнив следующую команду:
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>
Используйте применимый метод для проверки отношений организации:
Если облачному пользователю не удается просмотреть сведения о доступности для локального пользователя:
Убедитесь, что отношение локальной организации указывает облачный домен, который может получить доступ к локальной информации о доступности. Примером облачного домена является
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
Сбой веб-запроса прокси-сервера. , внутреннее исключение: произошла ошибка при обработке маркеров безопасности в сообщении.
Эта ошибка может возникнуть, если сертификаты или метаданные в шлюзе федерации Майкрософт недопустимы.
Действия по устранению неполадок
Проверьте дату окончания срока действия и отпечатки сертификатов доверия локальной федерации, выполнив следующие командлеты PowerShell:
Get-FederationTrust | FL Test-FederationTrust Test-FederationTrustCertificate
Чтобы обновить метаданные в шлюзе федерации Майкрософт, выполните следующую команду два раза в локальной командной консоли 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.
Решение
Для устранения данной проблемы выполните следующие действия:
Выполните следующий командлет PowerShell в командной консоли Exchange (EMS), чтобы получить отпечаток сертификата OAuth, используемого конфигурацией проверки подлинности:
Get-AuthConfig | FL CurrentCertificateThumbprint
Если выходные данные команды не возвращают отпечаток сертификата, перейдите к шагу 3. В противном случае перейдите к следующему шагу.
Выполните следующий командлет PowerShell, чтобы проверить, существует ли сертификат, указанный на шаге 1, в Exchange Server:
Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
Если Exchange Server не возвращает сертификат, перейдите к шагу 3, чтобы создать новый сертификат.
Если Exchange Server возвращает сертификат, но его отпечаток отличается от отпечатка, полученного на шаге 1, перейдите к шагу 4. На шаге 4 укажите отпечаток сертификата, возвращенного Exchange Server.
Выполните следующий командлет 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 укажите отпечаток нового сертификата, созданного на этом шаге.
Выполните следующие командлеты PowerShell, чтобы обновить конфигурацию проверки подлинности для использования указанного сертификата:
$date=Get-Date Set-AuthConfig -NewCertificateThumbprint <certificate thumbprint> -NewCertificateEffectiveDate $date Set-AuthConfig -PublishCertificate
Примечание.
Если вы получите предупреждение о том, что дата вступления в силу не превышает 48 часов, выберите продолжение.
Выполните следующий командлет PowerShell, чтобы удалить все ссылки на предыдущий сертификат:
Set-AuthConfig -ClearPreviousCertificate
В приложении отсутствует связанная учетная запись для ролей RBAC, либо связанная учетная запись не имеет назначений ролей RBAC, либо учетная запись вызывающих пользователей отключена.
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя. При диагностике проблемы отображается следующее сообщение об ошибке:
System.Web.Services.Protocols.SoapException: в приложении отсутствует связанная учетная запись для ролей RBAC, либо связанная учетная запись не имеет назначений ролей RBAC, либо учетная запись вызывающего пользователя отключена.
Действия по устранению неполадок
Чтобы устранить неполадки, упомянутые в сообщении об ошибке, выполните следующие действия. После выполнения шагов 1 и 2 проверьте, устранена ли проблема с доступностью.
Убедитесь, что запись "Exchange Online-ApplicationAccount" существует в списке партнерских приложений Exchange Server. Чтобы проверить это, выполните следующий командлет PowerShell в консоли управления Exchange (EMS):
Get-PartnerApplication | FL LinkedAccount
Запись учетной записи должна отображаться как
<root domain FQDN>/Users/Exchange Online-ApplicationAccount
. Если запись указана, перейдите к шагу 2.Если запись учетной записи отсутствует в списке, добавьте учетную запись, выполнив следующие действия:
Выполните следующие командлеты 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.
Выполните следующий командлет PowerShell, чтобы добавить учетную запись Active Directory в список партнерских приложений Exchange Server:
Set-PartnerApplication "Exchange Online" -LinkedAccount "<root domain FQDN>/Users/Exchange Online-ApplicationAccount"
Перезапустите все локальные серверы Exchange или iis, выполнив
iisreset /noforce
команду в PowerShell или окне командной строки на каждом сервере.
Выполните следующий командлет PowerShell в EMS, чтобы проверить назначения управления доступом на основе ролей (RBAC):
Get-ManagementRoleAssignment -RoleAssignee "Exchange Online-ApplicationAccount" | FL Name,Role
Например, в выходных данных команды могут быть перечислены следующие назначения ролей:
Выполните поиск в следующих журналах на наличие проблем, указанных в сообщении об ошибке:
- Журналы веб-служб Exchange (EWS), расположенные в папке %ExchangeInstallPath%\Logging\Ews
- Журналы событий приложения
- Журналы системных событий
Найдите в журналах, перечисленных на шаге 3, сообщение об ошибке, ссылающееся на AuthzInitializeContextFromSid. Если вы обнаружили это сообщение об ошибке, ознакомьтесь со следующими ресурсами:
Введенные и сохраненные пароли не совпадают.
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя. При диагностике проблемы отображается следующее сообщение об ошибке:
Получено исключение ошибки Soap. Введенные и сохраненные пароли не совпадают.
То же сообщение об ошибке отображается при выполнении следующего командлета, чтобы проверить, может ли пользователь облака получить маркер делегирования для локального почтового ящика пользователя:
Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose
Причина
Существует несоответствие в учетных данных Azure для конкретных пользователей облака.
Решение
Для устранения данной проблемы выполните следующие действия:
Сброс пароля пользователя в облаке. Выберите тот же или другой пароль.
Обновите имя участника-пользователя (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>
Убедитесь, что
ImmutableId
значение локального объекта пользователя равно NULL.ImmutableId
Проверьте значение локального объекта пользователя, выполнив следующую команду в командной консоли Exchange (EMS):Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
В зависимости
ImmutableId
от значения используйте один из следующих методов.Значение ImmutableId равно NULL.
ImmutableId
Если значение равно NULL, переключите его значение:ImmutableId
Задайте для объекта удаленного почтового ящика имя участника-пользователя в облаке, выполнив следующий командлет PowerShell в EMS:Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
Пример:
Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com
.Синхронизируйте изменения в облако, выполнив следующие командлеты PowerShell в EMS:
Import-Module ADSync Start-ADSyncSyncCycle -PolicyType Delta
Чтобы убедиться, что
ImmutableId
значение обновлено, выполните следующий командлет PowerShell в Exchange Online PowerShell:Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
Верните
ImmutableId
объект удаленного почтового ящика в значение NULL, выполнив следующий командлет PowerShell в EMS:Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
Синхронизируйте изменения с облаком, выполнив следующий командлет 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
Эта ошибка может возникнуть при наличии проблем с сетью или временных проблем. Сообщение об ошибке является универсальным.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Чтобы исключить временные проблемы, убедитесь, что пользователь облака постоянно получает одно и то же сообщение об ошибке во время неоднократных попыток получить сведения о доступности локального пользователя.
Проверьте, можно ли получить маркер делегирования при выполнении каждого из следующих командлетов:
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.
Убедитесь, что Exchange Server имеет исходящий доступ в Интернет к обоим из следующих ресурсов:
Шлюз федерации Майкрософт (или сервер авторизации, если используется OAuth)
URL-адрес доступности для Microsoft 365:
https://outlook.office365.com/ews/exchange.asmx
Дополнительные сведения см. в разделах URL-адреса и диапазоны IP-адресов Microsoft 365 и Рекомендации по брандмауэру для федеративного делегирования.
Убедитесь, что системная учетная запись в Exchange Server имеет доступ к Интернету по следующим URL-адресам. Выполните следующие действия на каждом сервере Exchange.
Выполните следующую команду PsExec , чтобы запустить сеанс PowerShell, который запускает веб-браузер из системной учетной записи:
PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
Проверьте доступ в браузере (без 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.
Проверьте доступ в браузере (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 или сообщение об ошибке входа " Извините, но у нас возникли проблемы со входом".
Получите сведения о запросе доступности, проверив журналы веб-служб Exchange (EWS):
Создайте запрос на доступ к данным из Exchange Online.
Найдите запись в журналах EWS и проверьте значение в столбце
time-taken
. Журналы EWS находятся в папке %ExchangeInstallPath%\Logging\Ews .Проверьте журналы 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)
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Обновите имя участника-пользователя (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>
Проверьте правила, конечные точки и журналы AD FS.
Найдите ошибку, связанную с пользователем
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, переключите его значение:ImmutableId
Задайте для объекта удаленного почтового ящика имя участника-пользователя в облаке, выполнив следующий командлет PowerShell в EMS:Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
Пример:
Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com
.Синхронизируйте изменения в облако, выполнив следующие командлеты PowerShell в EMS:
Import-Module ADSync Start-ADSyncSyncCycle -PolicyType Delta
Чтобы убедиться, что
ImmutableId
значение обновлено, выполните следующий командлет PowerShell в Exchange Online PowerShell:Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
Верните
ImmutableId
объект удаленного почтового ящика в значение NULL, выполнив следующий командлет PowerShell в EMS:Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
Синхронизируйте изменения с облаком, выполнив следующий командлет 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
Проверьте параметры отношений с организацией. Дополнительные сведения см. в разделе Demystifying Hybrid Free/Busy.
Если сообщение об ошибке создается для пользователя облака, который не может просматривать сведения о доступности для локального пользователя, выполните следующие действия.
Запустите следующий командлет PowerShell:
Test-FederationTrust -UserIdentity <on-premises user> -Verbose -Debug
Повторно создайте доверие федерации. Дополнительные сведения см. в разделах Удаление доверия федерации и Настройка доверия федерации.
Результирующий набор содержит слишком много записей календаря
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
Время начала рабочего времени должно быть меньше или равно времени окончания рабочего времени, а часовой пояс рабочих часов должен быть установлен.
Решение
Для устранения данной проблемы выполните следующие действия:
Выполните следующий командлет PowerShell, чтобы проверить параметры календаря каждого почтового ящика в списке помещений, чтобы определить почтовый ящик комнаты с недопустимыми параметрами:
Get-DistributionGroupMember -Identity <room list name> | Get-MailboxCalendarConfiguration | FL Identity,WorkingHours*
Выполните следующий командлет 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
.
Эта ошибка может возникнуть, если параметры сервера авторизации Майкрософт недопустимы.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Обновите метаданные авторизации на указанном сервере авторизации Майкрософт, который является доверенным для Exchange. Выполните следующий командлет PowerShell в EMS (локально):
Set-AuthServer <name of the authorization server> -RefreshAuthMetadata
Подождите около 15 минут, чтобы команда вступила в силу полностью, или перезапустите IIS, выполнив
iisreset /noforce
команду в PowerShell или окне командной строки на каждом сервере Exchange Server.Проверьте параметры сервера авторизации Майкрософт в организации 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.
Решение
Чтобы устранить эту проблему, выполните следующие действия.
Определите, существует ли локальный сертификат OAuth Exchange Server в организации Exchange Online:
Выполните следующий командлет PowerShell в командной консоли Exchange (EMS), чтобы получить сертификат OAuth в Exchange Server:
Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
Выходные данные команды содержат
Thumbprint
значение .Выполните следующие командлеты 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 локальным сертификатом.
Замените существующий локальный сертификат сертификатом Exchange Online:
Выполните следующий командлет PowerShell, чтобы обновить отпечаток локального сертификата:
Set-AuthConfig -NewCertificateThumbprint <thumbprint of Exchange Online certificate> -NewCertificateEffectiveDate (Get-Date)
Если вы получите уведомление о том, что дата вступления сертификата в силу не превышает 48 часов, примите запрос на продолжение.
Выполните следующий командлет PowerShell, чтобы опубликовать локальный сертификат:
Set-AuthConfig -PublishCertificate
Выполните следующий командлет PowerShell, чтобы удалить все ссылки на предыдущий сертификат:
Set-AuthConfig -ClearPreviousCertificate
Перейдите к шагу 4.
Экспортируйте локальный сертификат авторизации, а затем отправьте его в организацию Exchange Online.
Выполните следующий командлет PowerShell, чтобы проверить, является ли имя субъекта-службы в конфигурации локальной проверки подлинности :
00000002-0000-0ff1-ce00-000000000000
Get-AuthConfig | FL ServiceName
Если значение имени субъекта-службы отличается, обновите имя субъекта-службы, выполнив следующий командлет PowerShell:
Set-AuthConfig -ServiceName "00000002-0000-0ff1-ce00-000000000000"
Сбой веб-запроса прокси-сервера: ответ не имеет правильного формата XML
Проблема
У вас есть облачный пользователь, который не может просматривать сведения о доступности для локального пользователя. При диагностике проблемы отображается следующее сообщение об ошибке:
Сбой веб-запроса прокси-сервера. Внутреннее исключение: ответ не имеет правильного формата XML
При выполнении тестов синхронизации, уведомлений, доступности и автоматических ответов для локального пользователя появляется следующее сообщение об ошибке:
Ответ, полученный от службы, не содержит допустимый XML-код.
Эти ошибки могут возникать по любой из следующих причин:
- Проблема с внешними веб-службами Exchange (EWS)
- Неправильная настройка сетевых устройств, таких как обратный прокси-сервер или брандмауэр
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Проверьте, может ли запрос о доступности из Exchange Online получить доступ к СЛУЖБАм IIS на сервере Exchange Server. Выполните запрос доступности и выполните поиск в журналах IIS на наличие записей с кодом
200 OK
состояния HTTP или401 Unauthorized
во время выполнения запроса. Эти записи указывают, что запрос доступности достиг IIS. Примечание. Метки времени в журналах IIS используют время в формате UTC.Если вы не нашли эти записи, проверьте журналы обратного прокси-сервера и брандмауэра, чтобы определить, где застрял запрос на доступность.
Выполните запрос о доступности, а затем выполните поиск в журнале приложений Exchange Server в средстве просмотра событий Windows на наличие записей, которые были сделаны во время запроса, чтобы сузить причину проблемы.
Не удается подключиться к удаленному серверу
Проблема
У вас есть локальный пользователь, который не может просматривать сведения о доступности для облачного пользователя. При диагностике проблемы отображается следующее сообщение об ошибке:
Не удалось связаться с
https://login.microsoftonline.com/extSTS.srf
., внутреннее исключение: не удается подключиться к удаленному серверу.
Эта ошибка может возникнуть, если одному или нескольким серверам Exchange не удается подключиться к URL-адресу шлюза федерации Майкрософт.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Выполните следующие командлеты 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
Убедитесь, что локальные серверы Exchange имеют исходящий доступ в Интернет к обоим из следующих ресурсов:
Шлюз федерации Майкрософт или сервер авторизации Майкрософт, если используется проверка подлинности OAuth.
URL-адрес доступности для Microsoft 365:
https://outlook.office365.com/ews/exchange.asmx
.
Дополнительные сведения см. в разделах URL-адреса и диапазоны IP-адресов Microsoft 365 иРекомендации по брандмауэру для федеративного делегирования.
Убедитесь, что системная учетная запись в Exchange Server имеет доступ к Интернету по следующим URL-адресам. Выполните следующие действия на всех серверах Exchange в организации.
Выполните следующую команду PsExec , чтобы запустить сеанс PowerShell, который запускает веб-браузер из системной учетной записи:
PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
Проверка доступа в браузере (без проверки подлинности 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.
Проверка доступа в браузере (проверка подлинности 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 неверны.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Выполните следующие командлеты 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.Обновите 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>
Убедитесь, что имя локального узла в сообщении об ошибке (например, )
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.
Это общая ошибка, связанная со службой автообнаружения.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Убедитесь, что автообнаружатель для затронутого пользователя возвращает URL-адрес веб-служб Exchange (EWS) для пользователя.
Запустите тест автонастройки электронной почты в клиенте Outlook затронутого пользователя, чтобы убедиться, что автообнаружение возвращает URL-адрес EWS для пользователя.
Убедитесь, что доступность работает между локальными пользователями, размещенными на разных серверах Exchange.
Если у вас есть подсистемы балансировки нагрузки, проверьте, вызвана ли проблема с подсистемами балансировки нагрузки. Для этого измените файл "Узлы Windows" (на компьютере, на котором установлен клиент Outlook пользователя), чтобы обходить подсистемы балансировки нагрузки и указывать на конкретный сервер клиентского доступа.
Если между локальными пользователями работает режим "свободная или занятая", проверьте, имеют ли все локальные серверы Exchange исходящий доступ к URL-адресам и диапазонам IP-адресов Microsoft 365.
Проверьте, может ли каждый сервер 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 или неправильно настроенная конечная точка.
Действия по устранению неполадок
После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
Убедитесь, что службы Windows, необходимые Exchange Server, запущены. Чтобы проверить состояние служб, выполните следующий командлет PowerShell на каждом сервере Exchange в организации:
Test-ServiceHealth
Используйте консоль служб, чтобы запустить все остановленные службы, необходимые для Exchange Server.
Убедитесь, что необходимые компоненты Exchange Server активны. Чтобы проверить состояние компонентов, выполните следующий командлет PowerShell на каждом сервере Exchange в организации:
Get-ServerComponentState <server name>
Чтобы активировать неактивный компонент, используйте командлет PowerShell Set-ServerComponentState .
Убедитесь, что запущены следующие пулы приложений IIS для веб-служб Exchange (EWS) и автообнаружения:
- MSExchangeServicesAppPool
- MSExchangeSyncAppPool
- MSExchangeAutodiscoverAppPool
Проверьте, допустима ли конечная точка автообнаружения. Выполните следующие действия:
Выполните следующие командлеты PowerShell, чтобы получить URL-адрес конечной точки автообнаружения из значений
DiscoveryEndpoint
параметра илиTargetAutodiscoverEpr
:Get-IntraOrganizationConnector | FL DiscoveryEndpoint Get-OrganizationRelationship | FL TargetAutodiscoverEpr
Перейдите по URL-адресу конечной точки автообнаружения в веб-браузере или выполните
Invoke-WebRequest -Uri "<endpoint URL>" -Verbose
командлет PowerShell, чтобы убедиться, что URL-адрес действителен. Желательно проверить URL-адрес из внешней сети.
Проверьте, является ли URL-адрес EWS допустимым, выполнив следующие действия.
Выполните следующие командлеты PowerShell, чтобы получить URL-адрес EWS из
TargetSharingEpr
значения параметра в параметрах организации:Get-IntraOrganizationConnector | FL TargetSharingEpr Get-OrganizationRelationship | FL TargetSharingEpr
Б. Перейдите по URL-адресу EWS в веб-браузере или выполните
Invoke-WebRequest -Uri "<endpoint URL>" -Verbose
командлет PowerShell, чтобы убедиться, что URL-адрес является допустимым. Желательно проверить URL-адрес из внешней сети.Проверьте журналы IIS на наличие запросов доступности, возвращающих код
503 Service Unavailable
состояния HTTP:Создайте запрос на доступ к данным из Exchange Online.
Проверьте наличие записей кода
503 Service Unavailable
состояния HTTP в журналах IIS в папке W3SVC1 для веб-сайта по умолчанию на каждом сервере Exchange Server. Путь к папке W3SVC1 —%SystemDrive%\inetpub\logs\LogFiles\W3SVC1
. Эти записи помогут определить сервер, на который возникла проблема.Если запрос доступности не зарегистрирован в папке W3SVC1 , проверьте, зарегистрирован ли запрос в журналах ошибок в папке HTTPERR на каждом сервере Exchange. Путь к папке HTTPERR —
%SystemRoot%\System32\LogFiles\HTTPERR
. Если запрос доступности регистрируется в журналах HTTPERR , проверьте наличие неправильно настроенных параметров IIS.
Проверьте заголовок ответа сервера, который вы получаете при подключении к локальному 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: время ожидания шлюза...
Эта ошибка может возникнуть, если гибридный агент в вашей организации настроен неправильно.
Решение
Чтобы устранить эту проблему, выполните следующие действия. После завершения каждого шага проверьте, устранена ли проблема с доступностью и свободой.
TargetSharingEpr
Проверьте значение параметра в параметрах организации. Значение должно выглядеть так:https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmx
. Чтобы определить значениеTargetSharingEpr
параметра, выполните следующие командлеты PowerShell:Get-IntraOrganizationConnector | FL TargetSharingEpr Get-OrganizationRelationship | FL TargetSharingEpr
TargetSharingEpr
Если значение параметра неверно:Запустите мастер гибридной конфигурации (HCW) и выберите Использовать классическую гибридную топологию Exchange.
Повторно запустите HCW и выберите Использовать современную гибридную топологию Exchange. Эта процедура заставляет HCW сбросить
TargetSharingEpr
значение параметра.
Проверьте состояние гибридной службы Microsoft на сервере, где установлен гибридный агент. Если служба остановлена, запустите ее.
Проверьте состояние гибридного агента. Если состояние неактивно:
Запустите мастер гибридной конфигурации (HCW) и выберите Использовать классическую гибридную топологию Exchange.
Повторно запустите HCW и выберите Использовать современную гибридную топологию Exchange. Эта процедура заставляет HCW переустановить гибридный агент.
Установите модуль PowerShell гибридного агента, а затем выполните командлет PowerShell Get-HybridApplication , чтобы найти внутренний URL-адрес, на который указывает гибридный агент.
Перейдите к внутреннему URL-адресу, который вы нашли на шаге 3. Устраните все обнаруживаемые ошибки, например ошибки сертификатов.
Настройте гибридный агент для направления запросов к подсистеме балансировки нагрузки , а не к серверу под управлением Microsoft Exchange Server, чтобы исключить проблемы, которые могут возникнуть на этом сервере.
Убедитесь, что гибридный агент поддерживает запросы о доступности и миграцию почтовых ящиков.