none
не подключается Outlook к DAG RRS feed

  • Общие обсуждения

  • Создан DAG из двух серверов с ролями CAS+Mailbox.
    Почта ходит только внутри, наружу выхода нет.
    В DNS создана запись mail, которая разрешается в два IP серверов.

    Resolve-DNS mail.xxx.xxx

    mail.xxx.xxx 172.18.2.2
    mail.xxx.xxx 172.18.2.3

    Для каждого сервера выпущен свой сертификат внутренним ЦС.
    Клиенты Outlook и OWA подключаются без проблем.

    Затем выпустили сертификат для общего имени, включили в него имена
    mail.xxx.xxx
    Autodiscover.xxx.xxx

    назначили этот сертификат на оба сервера.
    Переназначили виртуальные директории, указав InternalURL https://mail.xxx.xxx

    OWA подключается без проблем.

    А вот при подключении Outlook выскакивает окно логин/пароль и сообщение об ошибке:
    Обнаружена ошибка сертификата безопасности прокси-сервера. Имя сертификата безопасности не действительно или не соответствует имени конечного сайта mail.xxx.xxx
    Outlook не может выполнить подключение к прокси-серверу. (Код ошибки 0).
    19 августа 2017 г. 6:39

Все ответы

  • Потому что меняли из графики и забыли поменять Set-OutlookAnywhere  -InternalHostname "mail.xxx.xxx" -InternalClientsRequireSsl $true -ExternalHostname $null -SSLOffloading $false
    20 августа 2017 г. 5:35
  • InternalHostName                               :  mail.xxx.xxx
    InternalClientAuthenticationMethod       :  Ntlm
    InternalClientRequireSsl                       :  True
    ExternalHostname                               :
    ExternalClientAuthenticationMethod      :  Basic
    ExternalClientRequireSsl                      :  false

    InternalHostName                               :  mail.xxx.xxx
    InternalClientAuthenticationMethod      :   Ntlm
    InternalClientRequireSsl                       :  True
    ExternalHostname                                :
    ExternalClientAuthenticationMethod       :  Basic
    ExternalClientRequireSsl                       :  false

    SSlOffloading : false
    SSlOffloading : false

    с OWA проблем нет. Outlook по-прежнему не подключается...

    При попытке автоматической настройки выскакивает сообщение:
    Невозможно вручную настроить новую учетную запись Microsoft Exchange во время работы Outlook. Чтобы добавить учетную запись, настроенную вручную, закройте Outlook. В панели управления выберите значок "Почта" и нажмите кнопку "Учетные записи"

    Через панель управления подключить удалось. После выхода из Outlook и повторной загрузки -снова окно логин/пароль и все .... 


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

    21 августа 2017 г. 6:29
  • Вводим логин/пароль, снова просит..

    И неудивительно, надо же керберос настроить чтобы не просил.

    21 августа 2017 г. 6:35
  • Т.е. вот этих настроек AutoDiscover недостаточно?

    AutoDiscoverServiceCN               :  serv-exchange-1
    AutoDiscoverServiceClassName  :   ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri   :  https://mail.xxx.xxx/Autodiscover/Autodiscover.xml
    AutoDiscoverServiceGuid            :   77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope                :  {Default-First-Site-Name}

    AutoDiscoverServiceCN               :  serv-exchange-2
    AutoDiscoverServiceClassName  :   ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri   :  https://mail.xxx.xxx/Autodiscover/Autodiscover.xml
    AutoDiscoverServiceGuid            :   77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope                :  {Default-First-Site-Name}

    IISAuthenticationMethods  : {Ntlm,Negotiate}

    И надо еще в DNS создать запись Autodiscover, которая будет разрешаться в Ip серверов Exchange?

    Честно, нигде до этого не встречал что надо еще и Kerberos настраивать

    21 августа 2017 г. 8:50
  • Это потому, что бложики предпочитаете документации по продукту, которая лежит нетронутой.

    Разумеется, надо, как клиент то будет проходить проверку на втором сервере если сессия была на первом? Использоваться NTLM тогда будет.

    В DNS либо две А записи Autodiscover, иди один CNAME на Autodiscover на mail.xxx.xxx.

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

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

    21 августа 2017 г. 9:10
  • Создали в DNS две записи A для autodiscover, которые разрешаются в IP серверов Exchange.

    Выполнили настройки SPN в соответствии со статьей 

    serspn -l xxc\KERB$
    Зарегистрирован ServicePrincipalNames для CN=KERB,CN=Computers,DC=xxx,DC=xxx:
    HTTP/autodiscover.xxx.xxx
    HTTP/mail.xxx.xxx

    Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name, AlternateServiceConfiguration

    Name                                              : serv-exchange-1
    AlternateServiceConfiguration       : последний: 21.08.2017 15.24.43, xxx\KERB$
                                                              предыдущий: 21.08.2017 15.24.43, xxx\KERB$
                                                             ...

    Name                                              : serv-exchange-2
    AlternateServiceConfiguration       : последний: 21.08.2017 15.23.26, xxx\KERB$
                                                              предыдущий: 21.08.2017 15.20.09, xxx\KERB$
                                                            ...

    при попытке настроить способы аутентификации 
    Get-OutlookAnywhere serv-exchange-1 -ADPropertiesOnly | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,Ntlm

    не удалось выполнить операцию, поскольку объект serv-exchange-1.xxx.xxx\serv-exchange-1 не найден в serv-xx.xxx

    Откуда этот объект serv-exchange-1.xxx.xxx\serv-exchange-1появился?

    Сейчас у нас такая аутентифтикация:
    ExternalClientAuthenticationMethods               : Ntlm
    InternalClientAuthenticationMethods                : Ntlm
    IISAuthenticationMethods                                 :{Ntlm,Negotiate}

    Outlook не подключается 


    serspn -l xxc\KERB$
    Зарегистрирован ServicePrincipalNames для CN=KERB,CN=Computers,DC=xxx,DC=xxx:
    HTTP/autodiscover.xxx.xxx
    HTTP/mail.xxx.xxx

    Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name, AlternateServiceConfiguration

    Name                                              : serv-exchange-1
    AlternateServiceConfiguration       : последний: 21.08.2017 15.24.43, xxx\KERB$
                                                              предыдущий: 21.08.2017 15.24.43, xxx\KERB$
                                                             ...

    Name                                              : serv-exchange-2
    AlternateServiceConfiguration       : последний: 21.08.2017 15.23.26, xxx\KERB$
                                                              предыдущий: 21.08.2017 15.20.09, xxx\KERB$
                                                            ...

    при попытке настроить способы аутентификации 
    Get-OutlookAnywhere serv-exchange-1 -ADPropertiesOnly | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,Ntlm

    не удалось выполнить операцию, поскольку объект serv-exchange-1.xxx.xxx\serv-exchange-1 не найден в serv-xx.xxx

    Откуда этот объект serv-exchange-1.xxx.xxx\serv-exchange-1появился?

    Сейчас у нас такая аутентифтикация:
    ExternalClientAuthenticationMethods               : Ntlm
    InternalClientAuthenticationMethods                : Ntlm
    IISAuthenticationMethods                                 :{Ntlm,Negotiate}

    Outlook не подключается 

    21 августа 2017 г. 12:29
  • при попытке настроить способы аутентификации 
    Get-OutlookAnywhere serv-exchange-1 -ADPropertiesOnly | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,Ntlm

    не удалось выполнить операцию, поскольку объект serv-exchange-1.xxx.xxx\serv-exchange-1 не найден в serv-xx.xxx

    Сразу делайте без Get-OutlookAnywhere, т.е.

    Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,Ntlm

    И добавляйте ключи, если он пропросит, SSLOffloading там и пр.

    21 августа 2017 г. 12:54
  • Делали так. тоже самое сообщение

    не удалось выполнить операцию, поскольку объект serv-exchange-1.xxx.xxx\serv-exchange-1 не найден в serv-xx.xxx

    Что это за объект? Что-то явно не так настроили

    21 августа 2017 г. 13:06
  • SPN и Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus  вывод правильный.

    Да, где-то наковыряли.

    Возьмите из справки и сделайте по аналогии по примерам.

    Что это за объект? Что-то явно не так настроили

    Посмотрите полный вывод Get-OutlookAnywhere. Вестимо ,там будет этот объект.

    21 августа 2017 г. 13:21
  • кажется мы его победили.
    Пересоздали заново DAG
    Выполнили все настройки. В соответствии со статьей настроили Kerberos
    setspn -L xxx\KERB$
    Зарегистрирован ServicePrincipalNames для CN=KERB,CN=Computers,DC=xxx,DC=xxx:
    HTTP/autodiscover.xxx.xxx
    HTTP/mail-1.xxx.xxx

    Единственно, что оставили проверку подлинности NTLM.
    Когда была Negotiate все равно требовал пароль.
    Новые клиенты подключаются без проблем.
    Существующие, только после обновления профиля.

    Отсюда вопрос - как обновить существующие подключения? У нас почти 4000 пользователей и переподключать каждого руками нереально

    И еще такой момент обнаружили - при проверке билетов на клиенте среди прочих, отображается только SPN для общего имени, а для autodiscover нет:

    клиент: preu-pav@xxx.xxx
    сервер: http/mail-1.xxx.xxx@xxx.xxx
    .....

          http/autodiscover нет 

    Это нормально или как?

    23 августа 2017 г. 11:39
  • Победили это хорошо.

    Вообще в билете должны обе записи быть.

    Если Вы видите только для http/mail-1.xxx.xxx@xxx.xxx, то я предположу что внутренние клиенты не берут настройки Autodiscover, а используют кэшированные. Вообще, это странно.

    Два момента.

    Есть ли у вас SCP настроенная (и куда) Покажите-ка ее.

    Get-ClientAccessServer | ft Name, AutoDiscoverServiceInternalUri

    Ну и порядок я бы попробовал поменять, в зависимости от вывода поиграть с ключами в реестре (посмотрите в конец статьи)

    И какой аутлук версии?

    MAPI/HTTP используете?


    Когда Вы настройки все применили, сколько времени прошло?
    23 августа 2017 г. 11:50
  • get-ClientAccessServer | fl name, AutoDiscoverServiceInternalUri

    Name                                             : serv-exchange-1
    AutoDiscoverServiceInternalUri   : https://mail-1.xxx.xxx/Autodiscover/Autodiscover.xml

    Name                                             : serv-exchange-2
    AutoDiscoverServiceInternalUri   : https://mail-1.xxx.xxx/Autodiscover/Autodiscover.xml

    сервер Exchange 2013 cu9

    клиенты Outlook 2013,2010,2007. Правда на 2007 пока не тестировали

    После применения настроек сразу и пробовали. Потом через час примерно-  без изменений

    23 августа 2017 г. 12:38
  • AutoDiscoverServiceInternalUri   : https://mail-1.xxx.xxx/Autodiscover/Autodiscover.xml

    Вот и ответ.

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

    23 августа 2017 г. 13:35
  • сервер Exchange 2013 cu9 - Обновляйтесь, зачем грешить. А то выловите грабли закрытые давно, будет стыдно.

    Про MAPI/HTTP не увидел.

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

    23 августа 2017 г. 13:37
  • Совсем запутался.

    что еще надо поменять для Autodiscover?

    23 августа 2017 г. 13:38
  • AutoDiscoverServiceInternalUri   : https://mail-1.xxx.xxx/Autodiscover/Autodiscover.xml на

    AutoDiscoverServiceInternalUri   : https://Autodiscover.xxx.xxx/Autodiscover/Autodiscover.xml

    Тогда клиент заберет эту SCP по имени Autodiscover указывающего на оба ваши сервера, и затем подключится по ОА к имени mail.

    23 августа 2017 г. 13:42
  • Ссылку на Autodiscovery поменяли. пул перезапустили.

    С новыми подключениями проблем нет.

    А существующие по прежнему автоматом не подключаются. Долго висят на моменте загрузки профиля. Потом сообщение, что сервер недоступен.

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

    И еще по поводу билетов такая интересная штука. Клиентам билеты приходят по разному.

    Например один и тот же п/я.

    В Outlook 2010 ему пришел 1 билет autodiscovery, в Outlook 2013 - 2 (autodiscovery и mail-1).

    Некоторым не приходит ни одного.

    Но в основном по одному билету, причем это autodiscover. 

    24 августа 2017 г. 7:21
  • Например один и тот же п/я.

    В Outlook 2010 ему пришел 1 билет autodiscovery, в Outlook 2013 - 2 (autodiscovery и mail-1).

    Некоторым не приходит ни одного.

    Но в основном по одному билету, причем это autodiscover. 

    Ерунда какая-то. Нет разницы, 2010 или 2013, получить (при настройке выше вы должны) обе записи.

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

    Для существующих клиентов, которые не подключаются я вижу два пути.

    Первый.

    Удаляем настроенные профили для аутлука при помощи сценария, ГП или другого решения.

    Создаем политику автонастройки для профиля. Результат: все сделали автоматом, выдохнули.

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

    Можете распараллелить ресурсы и сделать обе задачи.

    24 августа 2017 г. 7:49
  • Ну и порядок я бы попробовал поменять, в зависимости от вывода поиграть с ключами в реестре (посмотрите в конец статьи)

    В статье упоминается настройка в шаблоне параметра DisableAutodiscovery

    Облазили все шаблоны для всех Outlook 2007-2013, подключили английский шаблон. Нет такой настройки!!!

    В настройка учетной записи - Exchange- только два параметра Автономная адресная книга и Режим кэширования.

    Что за шаблон такой хитрый у вас? Где взять?

    24 августа 2017 г. 12:01
  • В центре загрузкок МС, как обычно. Проблем-то нет его скачать. Не можете найти- создайте ключ с помощью GPP, и вся недолга. Этот шаблон тоже самое делает без всякой магии.
    24 августа 2017 г. 12:06
  • С ключом все понятно. 

    просто стало интересно с шаблоном. Вроде бы тоже из центра загрузок качали. Шаблон безопасности для Office. Из него взяли шаблон только для Outlook. Или это какой отдельный шаблон для настройки Autodiscovery?


    24 августа 2017 г. 12:38
  • Нет, обычный шаблон для 2013 офиса брал, в нем выбрал настройки аутлука насколько я помню.
    24 августа 2017 г. 12:47
  • нет там Disable Autodiscovery.
    24 августа 2017 г. 13:23
  • Прошу прощения. Нашли :) Правда только в шаблоне Office 2013.
    24 августа 2017 г. 13:43
  • А я уже собирался просить отсыпать того, чем вы там эт самое. Но я не думаю, что  шаблон сильно поможет- смотрите в два решения выше.
    24 августа 2017 г. 13:49
  • Есть новости какие-то?
    28 августа 2017 г. 16:15
  • Можно ли еще здесь продолжить обсуждение или надо создать новую тему?

    В продолжении темы кластера. При удалении профиля политикой и создании нового pst файлы надо подключать руками. Это категорически не нравится начальству, поэтому оно предложило такой вариант- оставить существующий почтовый сервер как есть, создать кластер из новых пустых серверов. И на него уже постепенно мигрировать п/я. Это осуществимо? Что-то пока не очень представляю как это делать, ведь получается что в работе будут два сервера одновременно и куда будут подключать клиенты?

    19 сентября 2017 г. 13:29
  • Можно ли еще здесь продолжить обсуждение или надо создать новую тему?

    Помечаем полезное сообщение как ответ, если мы решили проблему. Не надо забывать делать это.

     При удалении профиля политикой и создании нового pst файлы надо подключать руками. Это категорически не нравится начальству

    А потом будете опять подключать их руками. Как этого избежать? Никак, пст и в Африке пст. Купите дешевых локальных дисков и положите на них базы, не надо использовать дорогое мето на полках для почты.

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

    А в чём смысл сего действа? Ну создали новый кластер, ну мигрировали туда ящики, что выиграли-то, непонятно. Дважды место потратите для этого, а на пст опять его нет? Бред какой-то.

    Что-то пока не очень представляю как это делать, ведь получается что в работе будут два сервера одновременно и куда будут подключать клиенты?

    А в чём трудность?

    Вот ДАГ А, у него заполнены ссылки, клиенты находят его через автодискавер, получают ссылки от любого каса и перенаправляются (сюрприз) туда, где монтирована в данный момент активная копия.

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

    19 сентября 2017 г. 14:10
  • Выиграли, что мигрировать будем потихоньку. И решать проблемы по мере их поступления. Потому что если сразу всех перевести в кластер, утром пользователи загрузили почту, а у большинства пропали pst. 99% пользователей не знают (главное и не хотят знать) где у них эти файлы и как их подключить.  Се ля ви :( ИТ службу завалят звонками почта пропала!!! Начальство на такое не согласно.

    Т.е процесс такой же как при миграции с 2010 сервера?

    Ведь у нас получится 2 активные БД. Одна в DAG, одна на действующем (старом) сервере

    А CAS нас будет с общим именем, т.е отдельный сервер мы как CAS исключаем?

    19 сентября 2017 г. 15:13
  • Т.е процесс такой же как при миграции с 2010 сервера?

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

    Ведь у нас получится 2 активные БД. Одна в DAG, одна на действующем (старом) сервере

    Суть происходящего так и осталась за кадром? Как только ящик доедет до 100%, и запрос остановится, пользователь будет подключаться к новой базе. Т.е. Общее имя-работаем на старом сервере-создали запрос на перемещение-закончили-клиент опять подключается к старому имени и ему говорят- а твой ящик вот на сервере Б живет, а не здесь, иди туда. Вот и все.

    А CAS нас будет с общим именем, т.е отдельный сервер мы как CAS исключаем?

    Не понял ничего.

    19 сентября 2017 г. 15:20
  • Ну если мы создали DAG, то клиенты подключаются уже по новому имени и их будут перенаправлять на старый сервер пока ящик не мигрирует?
    19 сентября 2017 г. 15:28
  • Клиентам имя даг фиолетово, они подключаются (еще раз) по автодискавер, далее получают ссылки. Куда ссылки ведут, туда они и полезут. Как только ящик передвинется, клиент получит новый адрес. И подключится уже к нему прозрачно.

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

    19 сентября 2017 г. 15:35
  • 

    Понял, что не прав. Ничего нам нам миграция не даст, в результате получим те же проблемы.

    Поэтому копаем дальше.

    Разобрали DAG и пытаемся подключаться Outlook. С OWA вообще проблем нет.

    Outlook не подключается, ругается на сертификат со старым (общим именем). Заходим  через ПУ-Почта в настройки почты 

    в адресе URL для подключения к прокси-серверу Exchange стоит общее имя https://mail-1

    а в строке подключаться только к прокси-серверам, содержащим это имя в сертификате

    стоит имя сервера msstd:serv-exchange-1

    Меняем общее имя в адресе URL на serv-exchange-1 и подключаемся

    Смотрим состояние подключения - подключения идут куда-надо на serv-exchange-1

    Смотрим автоконфигурацию

    Попытка поиска URL-адреса https://serv-exchange-1.xxx.xxx/autodiscover/autodiscover.xml через точку подключения службы

    Автооьнаружение для https://serv-exchange-1.xxx.xxx/autodiscover/autodiscover.xml начато

    ...

    Автообнаружение для https://serv-exchange-1.xxx.xxx/autodiscover/autodiscover.xml успешное завершение

    Вроде бы все нормально.

    А вот дальше смотрим вкладку результаты а там некоторые параметры остались старые с общим именем

    в частности

    Внутренний URL-адрес Outlook Web Access: https://mail-1/owa

    Протокол: Exchange HTTP

    Сервер: mail-1

    Протокол SSL: Да

    Взаимная проверка подлинности: Да

    Пакет проверки подлинности: NTLM

    Имя участника сертификата: msstd:serv-exchange-1

    На сервере вывод команды OutlookAnyWhere InternalHostname - serv-exchange-1.

    Выходит у нас файл autodiscover кривой?

    23 сентября 2017 г. 7:47
  • Outlook не подключается, ругается на сертификат со старым (общим именем). Заходим  через ПУ-Почта в настройки почты 

    в адресе URL для подключения к прокси-серверу Exchange стоит общее имя https://mail-1

    а в строке подключаться только к прокси-серверам, содержащим это имя в сертификате

    стоит имя сервера msstd:serv-exchange-1

    Волшебная команда, меняющая настройки сертификата для провайдера выглядит так:

    Set-OutlookProvider -Name EXPR -CertPrincipalName msstd:тотfqdn, который нужен. У Вас сейчас он там как я понял, mail-1. И Вас это пока удивляет.

    23 сентября 2017 г. 8:04
  • Нет, вывод Get-OutlookProvider | fl name, CertPrincipalname
     name                    :  EXCH
    certPrincipalName: msstd:serv-exchange-1

    name                    :  EXPR
    certPrincipalName: msstd:serv-exchange-1

    name                    :  WEB
    certPrincipalName: 

    и как раз имя сертификата показывает правильное, а вот адрес URL для подключения старый - mail-1
    23 сентября 2017 г. 8:15
  • Ну если вывод правильный, то очистка пула автодискавера поможет раздавать правильные, новые измененные настройки.

    Хотя, 

    а вот адрес URL для подключения старый - mail-1

    A Вы меняли адрес для Outlook Anywhere?

    23 сентября 2017 г. 8:19
  • Вывод OutlookAnyWhere
    Servername                                        :  Serv-exchange-1
    SSLOffloading                                    : True
    ExternalHostname                               :
    InternalHostname                               : serv-exchange-1
    ExternalClientAuthenticationMethod: Basic
    InternalClientAuthenticationMethod : Ntlm
    IISAuthenticationMethod                  : {ntlm}
    ExternalClientrequiresSSL                 : false
    InternalClientrequiresSSL                  :True

    Очитска пула autodiscover - это через диспетчер служб IIS - пулы приложений -MSExchangeAutodiscoverAppPool - перезапуск?
    23 сентября 2017 г. 9:11
  • Да, это перезапуск.
     И после этого автодискавер должен отдавать новые настройки виртуальных директорий. Всех, так что проверяйте.
    23 сентября 2017 г. 10:27
  • Отдает все настройки кроме URL прокси сервера. он по прежнему общий.

    Меняли настройки вчера вечером, минут через 5 пытались подключиться- практически все параметры были еще старые. Сегодня с утра остался только URL старый. отсюда возникает вопрос какова скорость обновления параметров и что на нее может влиять?

    Нельзя ли как-то поменять параметры вручную, например, через ADSI?

    23 сентября 2017 г. 11:08
  • Скорость зависит от кэша пула автодискавера, он раз в сутки точно сам обновляется. Раз Вы его почистили- то получите новые настройки, будьте уверены.

    Сейчас аутлук подключается?

    Нельзя ли как-то поменять параметры вручную, например, через ADSI?

    Чем powershell-то не устраивает? Можно, идите и меняйте на здоровье. Он же тоже самое за Вас делает по факту- правит лдап объекты в каталоге.

    23 сентября 2017 г. 11:23
  • Нет, вывод Get-OutlookProvider | fl name, CertPrincipalname
     name                    :  EXCH
    certPrincipalName: msstd:serv-exchange-1
    и как раз имя сертификата показывает правильное, а вот адрес URL для подключения старый - mail-1

    А вы можете это поле менять, оно не серое случайно?

    А то может переопределили скажем групповыми политиками и удивляетесь.

    24 сентября 2017 г. 10:14