Outlook 2013 не подключается к exchange
Обновлено: 07.07.2024
Добрый день.
Проводил миграцию с Exchange2010 на Exchange 2013.
Почта ходит, OWA работает, на Андроиде клиент работает, но Outlook не подключается.
До того как я полез все исправлять Outlook подключался с включенным VPN, теперь не подключается и изнутри и извне.
Настройка почтового ящика обрывается на моменте подключения к серверу: "Не принимает логин и пароль"
Тест выдает:
The Outlook connectivity test failed.
Attempting each method of contacting the Autodiscover service.
The Autodiscover service couldn't be contacted successfully by any method.
Additional Details
Testing the SSL certificate to make sure it's valid.
The SSL certificate failed one or more certificate validation checks.
Additional Details
Validating the certificate name.
Certificate name validation failed.
Tell me more about this issue and how to resolve it
Additional Details
Testing the SSL certificate to make sure it's valid.
The SSL certificate failed one or more certificate validation checks.
Additional Details
Validating the certificate name.
The certificate name was validated successfully.
Additional Details
Certificate trust is being validated.
Certificate trust validation failed.
Additional Details
Attempting to contact the Autodiscover service using the DNS SRV redirect method.
The Microsoft Connectivity Analyzer failed to contact the Autodiscover service using the DNS SRV redirect method.
Additional Details
Testing the SSL certificate to make sure it's valid.
The SSL certificate failed one or more certificate validation checks.
Additional Details
Validating the certificate name.
The certificate name was validated successfully.
Additional Details
Certificate trust is being validated.
Certificate trust validation failed.
The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate
A certificate chain couldn't be constructed for the certificate.
Эта статья применяется только к вопросам подключения Outlook майкрософт, вызванным требованием шифрования RPC.
Симптомы
Не удается Microsoft Office Outlook. Невозможно открыть окно Outlook. Не удалось открыть набор папок.
Не удалось открыть папки электронной почты по умолчанию. Компьютер Microsoft Exchange Server не доступен. Либо возникают проблемы с сетью, либо Microsoft Exchange Server компьютер для обслуживания.
Подключение к Microsoft Exchange Server недоступно. Outlook для выполнения этого действия необходимо быть в сети или подключаться к сети.
Не удалось открыть папки электронной почты по умолчанию. Не удалось открыть банк данных.
Outlook не удалось войти в систему. Убедитесь, что вы подключены к сети и используете правильное имя сервера и почтового ящика. Подключение к Microsoft Exchange Server недоступно. Outlook для выполнения этого действия необходимо быть в сети или подключаться к сети.
Однако если вы используете кэшировали профиль режима, Outlook не отображается ошибка. Вы можете испытывать следующие симптомы:
Outlook начинается в состоянии Отключено (в нижнем правом углу окна Outlook отображается "Отключено", скриншот состояния показан ниже).
Не удалось выполнить действие. Подключение к Microsoft Exchange Server недоступно. Outlook для выполнения этого действия необходимо быть в сети или подключаться к сети.
Имя не удалось разрешить. Подключение к Microsoft Exchange Server недоступно. Outlook для выполнения этого действия необходимо быть в сети или подключаться к сети.
Outlook не удалось войти в систему. Убедитесь, что вы подключены к сети и используете правильное имя сервера и почтового ящика. Подключение к Microsoft Exchange Server недоступно. Outlook для выполнения этого действия необходимо быть в сети или подключаться к сети.
Имя не удалось разрешить. Не удалось выполнить действие.
Не удалось разрешить имена серверов или почтовых ящиков.
Решение
Если вы используете один из автоматизированных методов (групповой политики или файл prf), убедитесь, что вы полностью протестировали метод, прежде чем развернуть его в большом масштабе.
Метод 1. Обновление или создание Outlook с помощью шифрования RPC
Вручную обновим существующий профиль
Чтобы вручную обновить существующий Outlook, чтобы он использовал шифрование RPC, выполните следующие действия:
В панели управления откройте элемент Mail.
Выберите показать профили.
Выберите профиль и нажмите кнопку Свойства.
Выберите учетные записи электронной почты.
В диалоговом окне с сервером почтовых ящиков и именем пользователя выберите дополнительные Параметры.
В диалоговом окне Microsoft Exchange откройте вкладку Безопасность.
Выберите шифрование данных между Microsoft Office Outlook и Microsoft Exchange > ОК (снимок экрана для этого шага см. здесь).
Выберите Далее > Готово.
Выберите Закрыть > закрыть > ОК.
Развертывание параметра групповой политики для обновления существующих профилей Outlook с помощью шифрования RPC
С точки зрения клиента развертывание параметра шифрования Outlook-Exchange, вероятно, является простейшим решением для организаций с Outlook клиентами. Это решение включает одно изменение на сервере (контроллер домена), и клиенты автоматически обновляются после загрузки политики клиенту.
Outlook 2010
По умолчанию параметр шифрования RPC включен в Outlook 2010 г. Поэтому развертывать этот параметр следует только с помощью групповой политики по следующим причинам:
- Исходное Outlook 2010 года отключено шифрование RPC между Outlook и Exchange.
- Необходимо запретить пользователям изменять параметр шифрования RPC в Outlook профиле.
Шаблон групповой политики по умолчанию Outlook 2010 г. содержит параметр Групповой политики, который Outlook-Exchange шифрование RPC. Чтобы обновить существующие Outlook 2010 с помощью групповой политики, выполните следующие действия:
Добавьте файл .adm в контроллер домена.
Действия по добавлению файла .adm в контроллер домена различаются в зависимости от Windows запущенного файла. Кроме того, поскольку политика может применяться к организационному подразделению, а не к домену, действия могут также отличаться для этого аспекта применения политики. Поэтому ознакомьтесь с Windows документацией.
Перейдите на шаг 3 после добавления шаблона .adm в редактор локальной групповой политики.
В статье Конфигурация пользователя разойдите административные шаблоны (ADM), чтобы найти узел политики для шаблона. С помощью шаблона Outlk14.adm этот узел будет Microsoft Outlook 2010, русская версия.
В Параметры учетной записи выберите узел Exchange (снимок экрана для этого шага см. здесь).
Дважды нажмите кнопку Включить параметр политики шифрования RPC.
На вкладке Параметр выберите Включено.
На этом этапе параметр политики будет применяться на рабочих станциях Outlook клиента при репликации обновления групповой политики. Чтобы проверить это изменение, запустите следующую команду:
После запуска этой команды запустите редактор реестра на рабочей станции, чтобы убедиться, что на клиенте существуют следующие данные реестра:
Если вы видите эти данные реестра в реестре, к этому клиенту применяется параметр групповой политики. Начните Outlook, чтобы убедиться, что изменение устраняет проблему.
Outlook 2013
По умолчанию параметр шифрования RPC включен в Outlook 2013 г. Поэтому развертывать этот параметр следует только с помощью групповой политики по следующим причинам:
- Исходное Outlook 2013 года отключено шифрование RPC между Outlook и Exchange.
- Необходимо запретить пользователям изменять параметр шифрования RPC в Outlook профиле.
Шаблон групповой политики по умолчанию Outlook 2013 г. содержит параметр групповой политики, который Outlook-Exchange шифрование RPC. Чтобы обновить существующие Outlook 2013 года с помощью групповой политики, выполните следующие действия:
Добавьте файлы .admx и .adml в контроллер домена. Это добавляет шаблон Outlook ADM, чтобы сделать его доступным в редакторе локальной групповой политики.
Действия по добавлению файлов .admx и adml в контроллер домена различаются в зависимости от версии Windows, которую вы работаете. Кроме того, поскольку политика может применяться к организационному подразделению, а не к домену, действия могут также отличаться для этого аспекта приложения политики. Поэтому ознакомьтесь с документацией Windows подробных сведений. (Эта статья помечена для Office 2010 г. Однако это также относится к Office 2013 г.).
Запустите редактор локальной групповой политики.
В статье Конфигурация пользователя разойдите административные шаблоны (ADM), чтобы найти узел политики для шаблона. При использовании шаблона Outlk15.admx этот узел будет Microsoft Outlook 2013 .
В Параметры учетной записи выберите узел Exchange (снимок экрана для этого шага см. здесь).
Дважды нажмите кнопку Включить параметр политики шифрования RPC.
На вкладке Параметр выберите Включено.
На этом этапе параметр политики будет применяться на рабочих станциях Outlook клиента при репликации обновления групповой политики. Чтобы проверить это изменение, запустите следующую команду на рабочей станции:
После запуска этой команды запустите редактор реестра на рабочей станции, чтобы убедиться, что на клиенте существуют следующие данные реестра:
Если вы видите эти данные реестра в реестре, к этому клиенту применяется параметр групповой политики. Начните Outlook, чтобы убедиться, что изменение устраняет проблему.
Метод 2. Отключение требования шифрования на всех серверах CAS
Корпорация Майкрософт настоятельно рекомендует оставить требование шифрования включено на сервере и использовать один из других методов, перечисленных в этой статье. Метод 2 представлен в этой статье только для ситуаций, в которых невозможно немедленно развернуть необходимые параметры шифрования RPC на Outlook клиентах. Если вы используете Метод 2, чтобы разрешить Outlook клиентам подключаться без шифрования RPC, повторно включении требования шифрования RPC на серверах CAS как можно быстрее для поддержания максимально высокого уровня связи между клиентом и сервером.
Чтобы отключить необходимое шифрование между Outlook и Exchange, выполните следующие действия:
Выполните следующую команду в Командная консоль Exchange:
Местообладатель Exchange_server_name представляет имя Exchange Server, который имеет роль сервера клиентского доступа.
Этот список должен быть запущен для всех серверов клиентского доступа, которые работают Exchange Server версии 2010 или более поздней версии.
Перезапуск этой команды для каждого Exchange сервера, который имеет роль сервера клиентского доступа. Команду также необходимо выполнить на каждой роли сервера почтовых ящиков, которая содержит хранилище общедоступных папок. Подключение к общедоступным папкам от клиента MAPI напрямую передается в службу клиентского доступа RPC на сервере почтовых ящиков.
После обновления Outlook с параметром, позволяющим включить зашифрованную связь RPC с Exchange (см. ниже шаги), вы можете повторно включить требование шифрования RPC на Exchange серверах, которые имеют роль сервера клиентского доступа.
Чтобы повторно включить требование шифрования RPC на Exchange серверах с ролью сервера клиентского доступа, запустите следующую команду в командной Exchange:
Местообладатель Exchange_server_name представляет имя сервера Exchange, который имеет роль сервера клиентского доступа.
Этот список должен быть запущен для всех серверов клиентского доступа, которые работают Exchange Server версии 2010 или более поздней версии.
Причина
Одна из возможных причин — использование Outlook и отключение данных шифрования между Microsoft Office Outlook и microsoft Exchange профилем. Конфигурация по умолчанию для Exchange Server 2013 года требует шифрования RPC от Outlook клиента. Это не позволяет клиенту подключаться.
Конфигурация Exchange Server 2010 выпуска для производства (RTM) требует шифрования RPC. Это поведение является изменением Exchange Server 2010 Пакет обновления 1, когда требование шифрования RPC отключено по умолчанию. Однако любой сервер клиентского доступа (CAS), развернутый до Пакет обновления 1 или обновленный до Пакет обновления 1, сохранит существующий параметр шифрования RPC, который по-прежнему может помешать клиенту подключиться.
Примечание: Мы стараемся как можно оперативнее обеспечивать вас актуальными справочными материалами на вашем языке. Эта страница переведена автоматически, поэтому ее текст может содержать неточности и грамматические ошибки. Для нас важно, чтобы эта статья была вам полезна. Просим вас уделить пару секунд и сообщить, помогла ли она вам, с помощью кнопок внизу страницы. Для удобства также приводим ссылку на оригинал (на английском языке) .
Причина: ваша организация использует Exchange Server 2003 или более раннюю версию.
Решение: обратитесь к администратору своей учетной записи, чтобы узнать, под управлением какой версии Exchange Server она работает.
Outlook для Mac поддерживает учетные записи, управляемые сервером Microsoft Exchange Server 2007 с пакетом обновления 1 и накопительным пакетом обновления 4 (KB952580), а также более поздними версиями.
Причина: учетные данные вашей учетной записи или имя сервера Exchange неверны.
Решение: проверьте параметры своей учетной записи.
В меню Сервис выберите команду учетные записи.
В левой области диалогового окна Учетные записи выберите учетную запись.
Проверьте, правильно ли заданы параметры учетной записи.
Совет: Чтобы убедиться в том, что вы используете верные учетные данные, попробуйте подключиться к учетной записи из другого приложения Exchange, например из Outlook Web App.
Причина: приложение Outlook настроено для работы в автономном режиме.
Решение: убедитесь в том, что Outlook подключен к Интернету.
В меню Outlook снимите флажок Автономный режим.
Причина: сетевое подключение недоступно.
Решение: убедитесь в том, что компьютер подключен к сети.
Инструкции по проверке состояния сетевого подключения см. в справке Mac OS. Кроме того, вы можете обратиться к администратору сервера Exchange или к администратору сети. Наконец, можно спросить коллег, которые используют схожие параметры, могут ли они подключиться к сети. Или, если вы подключены к своей учетной записи Exchange через Интернет, попробуйте использовать веб-браузер, чтобы проверить наличие доступа к сайтам в Интернете.
Причина: недоступен сервер, на котором работает программное обеспечение Microsoft Exchange Server.
Решение: проверьте подключение к серверу Microsoft Exchange Server.
В меню Сервис выберите учетные записи.
В области слева найдите учетную запись Exchange. Если есть проблема с подключением, значок индикатора будет оранжевым.
Если вы успешно подключались к учетной записи раньше, попробуйте подключиться к ней из другого приложения Exchange, например из Outlook Web App. Чтобы проверить состояние сервера Exchange, можно также обратиться к его администратору.
Причина: учетная запись Exchange требует входа в систему с помощью канала с криптографической защитой.
Решение: обратитесь к администратору Exchange, чтобы узнать, требуется ли для учетной записи канал с криптографической защитой, и, если это так, проверьте параметр для этого канала.
В меню Сервис выберите учетные записи.
В левой области диалогового окна Учетные записи выберите учетную запись.
Выберите команду Дополнительно и выберите вкладку сервер.
В разделах Microsoft Exchange и Служба каталогов установите флажки Использовать SSL для подключения.
Причина: для подключения к серверу Exchange компьютеру требуется почтовый прокси-сервер.
Решение: обратитесь к администратору своей учетной записи Microsoft Exchange.
Спросите у администратора, какой прокси-сервер следует использовать для подключения к серверу Microsoft Exchange. Сведения о том, как настроить подключение к прокси-серверу, см. в справке Mac OS.
MaxKozlov,Алексей, у вас явно autodiscover не может нормально работать.
по кодам ошибок смотрели ? какие из указанных путей действительны ?
Если что-то не существует, то и ссылок туда быть не должно.
проверить dns, проверить доступность соответствующих путей с проблемных машин.
проверить настройки autodiscover в exch.
Алексей, в дополнение к советам MaxKozlov :
P.S. проблемные клиенты, случайно, не с собственными ноутами шарахаются?
Роман Безруков,
Нет, рабочими доменными ПК. Данный "прикол" появился сразу после выпуска сертификата
а что прописано в сертификате (интересует поле SAN) и к каким сервисам Exchange он привязан. и речь, если я правильно помню, про серт от LE?
P.S. буквально дней 10 назад без проблем обновил клиентам сервера Exchange до последних CU вкупе с сертификатами LE.
Роман Безруков, Привязан к IIS, IMAP, SMTPГде посмотреть то, что прописано в сертификате? :| Алексей,
Get-ExchangeCertificate YourCertThumbprint | select CertificateDomains SAN в сертификате вроде как в "DnsNameList" и оно должно совпадать с тем что выдаёт об autodiscover команда от Роман Безруков
MaxKozlov, Роман Безруков, Господа, если я правильно всё понял, то было выпущено два сертификата (16.10 и 18.10). Те, кто подхватывают старый серт не попадают на эксч, а те, кто новый соответственно, попадают. Как мне проверить свою теорию и насколько она имеет право на жизнь?
Алексей, удалить на сервере Exchange серт от 16.10 и выполнить iisreset /restart (возможно, еще потребуется перезапустить Microsoft Exchange Transport), после чего проверять работу Алексей, нет где? на сервере Exchange в консоли certlm.msc в Personal (а еще может быть в доверенных корневых и/или доверенных промежуточных) или в выводе Get-ExchangeCertificate?OWA/ECP какие серты показывают? Роман Безруков, В консоли нет. В выводе команды его тоже нет.
Ова показывает нормальный серт, а екп показывает нерабочий сертификат
иногда бывает что конфиг, который выдаёт exch по get-exchangecertificate не совпадает с тем что написано в web.config
У меня бывало именно что старый сертификат "залип" в iis, хотя exch был уверен что всё уже заменилось
в таких случаях с помощью enable-exchangecertificate нужный сертификат можно переприсвоить сервисам.
и, на крайняк, в оснастке iis можно выбрать. другой, а потом обратно нужный
на всех серверах Exchange принудительно выполните:
Enable-ExchangeCertificate -Thumbprint <отпечаток работающего серта> -Services SMTP,IIS -Force
iisreset /restart
restart-service "Microsoft Exchange Transport"
Но т.к. в почтовых делах я дуб дубом, а человек отвечающий за это тот еще. в общем теперь на меня это повесили :)
Куда тут смотреть и что делать не подскажете, люди добрые?
подчеркнутое красным - удалить
подчеркнутое синим - выполнить действия, описанные в моем предыдущем комментарии Роман Безруков, Роман, или я тупой (что наиболее вероятно) или лыжи не едут. Выполняю описанную Вами команду, но не может быть всё так просто.
Заранее прошу прощения за тупость :( Алексей, thumbprint - это строка. соответственно в "", а не <> и без пробелов
Роман <> отмечал местоположение обязательного параметра :) Алексей, "не помогло" - это означает что клиенты продолжают видеть неверный сертификат ? Алексей, да не может быть. IIS и Exchange Transport после перепривязки сертификата перезапущены?
Роман Безруков
Алексей, Попробуйте таки ещё через оснастку иис сертификат вручную выбрать. сначала другой, обязательно применить. потом тот что надо MaxKozlov, завтра попробую. Никогда с иисом не работал, не подскажете где это делается? Алексей, сам на память говорю :)
в его оснастке ищете сайт эксчейнджа. там их два- бэк и фронт. И в биндинге портов сайта смотрите сертификат Алексей, все сертификаты имеют закрытые ключи? через GPO никакие лишние сертификаты не распространяются? MaxKozlov, Back End висит на 444 порту и закрывается самоподписанным сертом с именем "Microsoft Exchange", выданным конкретным сервером - тут достаточно просто проверить привязки, даже ничего не меняя
а вот на Front End (он же Default Web Site) - там да, нужно потыкать в сертификаты Роман Безруков, MaxKozlov, пока до этого руки не дошли, но вот что странно: клиентам помогает получить нормальный серт в cmd ipconfig /flushdns Алексей, то есть если сбросить DNS кеш, ваши клиенты начинают видеть правильный сертификат ??
что-то мне кажется вам стоит внимательно посмотреть на свой DNS :) Роман Безруков, Не расскажите поподробней как это сделать? Никогда с этим "зверем" не сталкивался.. Роман Безруков,
Оно?
а вот первый скрин - весьма забавный.
Алексей, ну у меня on-premises Exchange 2013CU20-22 (забыл версию) и клиентские оутлуки при настроенном внутри autodiscover ломились в офис-365. При этом авторизация в офисе была через доменные УЗ. Так что не всё так гладко. Мне попадался документ с MSDN с описанием полного процесса поиска сервера оутлуком, и там 4м стоял этап потенциального поиска в облаке, который нет-нет да и выдавал трудноотлавливаемые ошибки. Поставил политику - всё, никаких больше проблем с подключением к почте.
Что может быть не так с DNS? Например, рассинхрон, пропадание записей autodiscover/SRV на одном из узлов, просто неверные данные для автонастройки изнутри или извне. А если проблемой был серт letsencrypt, проверяйте прокси/CAS'ы, чтобы сертификат везде был назначен и доступен
Читайте также: