Немного предыстории ... сеть взорвалась, перестроилась. Эта AD пережила людей, не знающих, что они делают, Exchange 2007 (устанавливался и удалялся несколько раз), Exchange 2010 (использовался в настоящее время и один раз повторно сделал после сбоя).
Мой Outlook Anywhere (RPC через HTTP) не работает, ответ XML находится ниже, и, насколько я могу судить, он предоставляет всю правильную информацию, но testexchangeconnectivity.com по-прежнему говорит: «Раздел поставщика EXCH отсутствует в ответе автообнаружения».
Я прошел через AD с тонкой гребенкой, и я считаю, что все в порядке (все правильно в службе Exchange при настройке в ADSIEDIT), хотя я, возможно, не ищу в нужных местах.
Мой внутренний и внешний URL одинаковы. Любые советы о том, где смотреть или любой вклад приветствуются!
<?xml version="1.0"?>
<Autodiscover xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>User Name</DisplayName>
<LegacyDN>/o=Org/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User Name</LegacyDN>
<DeploymentId>1f6566b1-18f9-43ae-a2f4-495916449c3f</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<MdbDN>/o=Org/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=TRITON/cn=Microsoft Private MDB</MdbDN>
<ASUrl>https://mail.domain.com/EWS/exchange.asmx</ASUrl>
<OOFUrl>https://mail.domain.com/EWS/exchange.asmx</OOFUrl>
<OABUrl>http://mail.domain.com/OAB/484c877c-a2ca-4ec7-b6eb-69c51c199245/</OABUrl>
<UMUrl>https://mail.domain.com/EWS/UM2007Legacy.asmx</UMUrl>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<CertPrincipalName>msstd:*.domain.com</CertPrincipalName>
<PublicFolderServer>ScuttleTwo.domain.com</PublicFolderServer>
<AD>Dewey.students.domain.com</AD>
<EwsUrl>https://mail.domain.com/EWS/exchange.asmx</EwsUrl>
<EcpUrl>https://mail.domain.com/ecp</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>mail.domain.com</Server>
<ASUrl>https://mail.domain.com/EWS/exchange.asmx</ASUrl>
<OOFUrl>https://mail.domain.com/EWS/exchange.asmx</OOFUrl>
<OABUrl>https://mail.domain.com/OAB/484c877c-a2ca-4ec7-b6eb-69c51c199245/</OABUrl>
<UMUrl>https://mail.domain.com/EWS/UM2007Legacy.asmx</UMUrl>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<SSL>On</SSL>
<AuthPackage>Basic</AuthPackage>
<CertPrincipalName>msstd:*.domain.com</CertPrincipalName>
<EwsUrl>https://mail.domain.com/EWS/exchange.asmx</EwsUrl>
<EcpUrl>https://mail.domain.com/ecp</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://mail.domain.com/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://mail.domain.com/EWS/exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://mail.domain.com/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://mail.domain.com/EWS/exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
</Account>
</Response>
</Autodiscover>
У меня была такая же проблема, и мне потребовалось немного покопаться, поскольку сообщение об ошибке средства удаленного подключения к Exchange вводит в заблуждение.
Для меня это оказалось ссылкой на недавно удаленный сервер CAS в свойстве RPCClientAccessServer баз данных. (В качестве некоторой предыстории, Exchange является новым в моей среде, и я настроил Exchange с некоторыми «тестовыми» именами хостов. Когда пришло время перейти к производственным именам хостов, я удалил тестовые серверы из среды ...)
Кажется, что RPCClientAccessServer не устанавливается динамически. Очевидно, поскольку это моя первоначальная реализация Exchange, я не эксперт, поэтому, если кто-нибудь может предоставить дополнительную информацию по этому поводу, пожалуйста, позвольте мне.
В любом случае, решение этой проблемы было таким же простым, как захват баз данных и сброс свойства RPCClientAccessServer с помощью PowerShell.
Например, следующая команда получает все базы данных на узле mailbox01 и устанавливает для RPCClientAccessServer значение newCAS02:
Get-MailboxDatabase -Server mailbox01.example.local | Set-MailboxDatabase -RPCClientAccessServer newCAS02.example.local
Обратите внимание, что это должны быть полные доменные имена.
Чтобы отдать должное там, где полагается кредит, я нашел здесь свое решение http://exchangeserverpro.com/outlook-clients-unable-to-connect-to-exchange-2010-after-client-access-server-role-moved
Я решил опубликовать его здесь, потому что в нем ничего не упоминается об ошибке «Отсутствует раздел поставщика EXCH», и это решение было немного сложно отследить.
Это немного сложно диагностировать на основе включенного отчета журнала. Я вижу там HTTPS, поэтому я бы проверил, импортировали ли вы свой сертификат SSL.
Вы упомянули, что Exchange 2010 - это то, что вы используете сейчас, перешли ли вы на SP1? Если вы можете это сделать, а затем следовать статье Microsoft TechNet, это должно быть лучшим местом для начала.
http://technet.microsoft.com/en-us/library/bb123741.aspx
есть также команда PowerShell Test-OutlookConnectivity
удачи, дайте нам знать, как это работает.