Exchange , Outlook не входит⁠⁠

Если не путаю, то встречал подобную фигню когда время на компах и сервере не совпадало.

столкнулся с аналогичной проблемой при переходе с 2019 cu14 на cu 15, также outlook не принимал пользовательский пароль и постоянно просил его ввести.

Оказалось, что обновление включает Exchange Extended Protection, которая блочит некоторых клиентов.

Если отключить ее через скрипт ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames srv1, srv2, то всех пускает норм

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

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

поэтому я всегда ставлю обновы с задержкой в один цикл/версию или в месяц или еще как. только 1с сразу же в прод летит.

в ку16 поправят. или в 17.

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

https://techcommunity.microsoft.com/discussions/exchange_gen...

как обычно есть еще иные проблемы

А в комментах выше уже было

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

Было какое-то время назад у нескольких клиентов проблемы, но с мобильными приложениями, ситуация была вызвана тем, что приложение в телефоне вместо домена .ru подставляло .local (в exchange было оба домена добавлены), если явно не указать какой домен используется.

Пробовали ThunderBird для теста?

Компы в домене?

При установке СU включается расширенная безопасность и отваливаются компы с NTLMv1

https://learn.microsoft.com/ru-ru/exchange/plan-and-deploy/p...

NTLMv1 can't be used together with Extended Protection. If you enforce a client to use NTLMv1 instead of NTLMv2 and you have Extended Protection enabled on your Exchange servers, this configuration leads to password prompts on the client side without a way to authenticate successfully against the Exchange server.

Откатите CU15 на CU14, это будет сделать проще, чем сейчас на живом сервере эксперименты ставить

Измени настройку уровня аутентификации в локальной групповой политике почтового сервера
Network Security: LAN Manager на Send NTLMv2 response only

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

Я так понимаю UPN у вас .local в AD, а почта звучит как v.pupkin@contoso.ru? Попробуйте добавить UPN пользователю не .local, а .ru, примените в AD на какому-нибудь пользаку и попробуйте залогиниться.

Измени настройку уровня аутентификации в локальной групповой политике почтового сервера
Network Security: LAN Manager на Send NTLMv2 response only

Ещё можно глянуть ветку реестра HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Какие там параметры указаны?

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

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

Попробуй с зажатым ctrl нажать пкм на иконку Outlook в трее, глянь линк, куда цепляться пытается
И нужно смотреть логи cas службы, что она пишет при попытке подключения

Попробуй с зажатым ctrl нажать пкм на иконку Outlook в трее, глянь линк, куда цепляться пытается
И нужно смотреть логи cas службы, что она пишет при попытке подключения

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