Outlook 2016-2019 долгий запуск и загрузка профиля
 

Добрый вечер!
Выручайте братцы, сломал весь мозг, перечитал кучу инфы, в основном одни и те же советы, часть которых и сам знал, ничего не помогло.
Ситуация следующая, есть Windows 10 LTSC билд 17763 поставленный с нуля, антивирус касперского, есть офис поставленный посредством утилиты Oinstall (хоть 2016, хоть 2019 - результат один), есть Exchange 2010. Заводим ПК в домен. Под юзером с админскими правами Outlook запускается отлично и быстро. Под юзером с простыми правами по долгу висит на загрузке профиля (до полу часа примерно), после запуска Outlook висит на переходах от письма к письму. Кэширование отключено. Через ГПО при запуске создаётся корпоративная подпись (всё это время прекрасно работало и не вызывало проблем).
Ситуация осложняется тем, что эти юзеры до этого работали на Win 7 и офисе 2010 и у них все прекрасно работало (так же почта прекрасно работает через браузер). Даже больше скажу, началось это примерно в декабре, ближе к концу, и те кому винду и офис ставил до того времени у них тоже все прекрасно работает.
Проблема вылезла именно с последними установками виндовс и офиса.
Пока не уверен точно, но в качестве эксперимента на одном таком ПК поставил офис не онлайн через Oinstall, а из оффлайн пакета созданного около года назад, и там ситуация получше, Outlook секунд на 10 задумывается при запуске и таки запускается и работает. Протестировал это пока только на одном ПК, так что точность результата не гарантируется.
Может быть есть у кого какие идеи в какую сторону копать и как таки понять в чём дело?

anatoly_neo, попробуйте Запуск Outlook в безопасном режиме и отключение надстроек.

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

в итоге поставил более старую версию офиса ( 16.0.12624.20466 (2020.04) ) а не скачанный офис посредством Oinstall и почта начала открываться, задержка правда все равно есть, но по крайней мере секунд 10-15, а не пол часа, и письма нормально листаются.
Это конечно не решение проблемы, хочется таки до сути докопаться, в чем беда... Неужто мелкомягкие внедрили что-то в офи (в последних обновлениях), что вот так вот валит Outlook ???

anatoly_neo, можете сделать лог Process Monitor следующим образом:

1. запустите Process Monitor от имени администратора;
2. запустите Outlook и спровоцируйте его зависание;
3. сохраните лог: меню File -> Save -> PML-формат;
4. заархивируйте и выложите на файлообменник, например dropmefiles.com.

Petya V4sechkin, лог снял, выложил сюда https://cloud.mail.ru/public/AyQZ/L3KF6kAR9

если здесь ничего интересного не будет, тогда в ближайшие дни настрою новый ПК и прям спецом спровоцирую ситуацию когда грузится по пол часа. Просто этот комп уже отдал в работу сотруднику и удалось добиться мало-мальски стабильной работы (запускается в районе 10-15 секунд), рушить не хочется.

anatoly_neo, в логе видна задержка 20 секунд.
В стеке при этом Windows.Security.Authentication.Web.Core.dll - намекает на проблему с аутентификацией Office.

Проверьте по статье
Connection issues in sign-in after update to Office 2016 build 16.0.7967 on Windows 10

P.S. Для эксперимента удалите Касперского.

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

Petya V4sechkin, Подскажите плиз, почитав статью понимаю что под мой случай подходит "Симптом 1", то есть получается надо чтобы у ПК был доступ к сайту указанному там и антивирус не блокировал указанные там exe файлы?

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

Спасибо за помощь, очень ценю!

anatoly_neo, точного соответствия по симптомам нет (у вас же только Outlook тормозит), но проблема как-то связана с аутентификацией.
И это согласуется с вашей ситуацией: начиная с некоторых сборок Office 2016 и Windows 10 сменился способ аутентификации с ADAL на WAM (диспетчер учетных веб-записей).

Поищите в Журналах приложений и служб -> Microsoft -> Windows -> AAD -> события, по времени совпадающие с зависаниями.

P.S. Кстати, служба Диспетчер учетных веб-записей в Windows 10 не отключена, случайно?

включена, запущена. тип запуска вручную.
Будем рыть AAD.
Только не очень понятно, если сменили тип на WAM то получается он теперь пытается подключиться к инет серверам мелкософта для чего-то? даже не взирая на то что чунга локальная?

Поставил на новый ПК свежую винду и офис 2019. При попытке запустить офис в AAD 4 предупреждения:

1)
Error: 0x80070002 Не удается найти указанный файл.
Exception of type 'class DSRegException' at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.

Log: 0xcaac03f1 Failed to get the DC registration data. Cannot get the domain name.
Logged at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.

2)
Error: 0xCAA9004D Account type is unknown.
Exception of type 'class Exception' at aggregatedtokenrequest.cpp, line: 157, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.

Logged at aggregatedtokenrequest.cpp, line: 159, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed6-52b3-4102-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c, resource: https://officeapps.live.com, correlation ID (request): 0fd253d0-d916-49bf-9161-9ebac2fce256

3)
Error: 0x80070002 Не удается найти указанный файл.
Exception of type 'class DSRegException' at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.

Log: 0xcaac03f1 Failed to get the DC registration data. Cannot get the domain name.
Logged at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.

4)
Error: 0xCAA9004D Account type is unknown.
Exception of type 'class Exception' at aggregatedtokenrequest.cpp, line: 157, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.

Logged at aggregatedtokenrequest.cpp, line: 159, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.

Request: authority: https://login.microsoftonline.com/common, client: d3590ed6-52b3-4102-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c, resource: https://api.office.net, correlation ID (request): dc98b904-73d5-49ed-8e7b-38232176dfd8

И такой же симптом, Outlook повисит секунд 20-30 и открывается.

Так же в AAD есть ошибки, но они возникают при запуске ПК:

1) Device is not cloud domain joined: 0xC00484B2
2) AAD Cloud AP plugin call Plugin initialize returned error: 0xC00484B2

Даже не знаю что и делать...

anatoly_neo, для эксперимента можно выставить параметры:
Затем создать заново профиль Outlook и посмотреть, изменится ли поведение при запуске.

Можем копнуть и в другом направлении: настройки автообнаружения (autodiscover) Exchange, например параметр:
(и в этом случае потребуется пересоздать профиль Outlook).

Petya V4sechkin,
Создал все указанные ключи.
теперь только две ошибки вида:

1) Не удается найти описание для идентификатора события 1089 из источника Microsoft-Windows-AAD. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере.

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

К событию были добавлены следующие сведения:

3221521586

Неверный дескриптор

2) Не удается найти описание для идентификатора события 1104 из источника Microsoft-Windows-AAD. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере.

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

К событию были добавлены следующие сведения:

Plugin initialize
3221521586

Неверный дескриптор


И обе они при запуске компа.
Но почта так и загружается с затупом секунд в 30. :(
Может быть ещё куда то можно посмотреть в журналах, где могут что-то интересное написать?
Нет ли какого-то журнала коннекта в самой чунге?

anatoly_neo, "чунга" - это Exchange?

Посмотрите варианты
Медленный Exchange Autodiscover в Outlook 2016

P.S. Очередная попытка анализа лога, кажется, начала прояснять ситуацию (но это не точно). Последовательность примерно такая:

1. Outlook через Windows.Security.Authentication.Web.Core обращается к службе Диспетчер учетных веб-записей (TokenBroker) и ждет ответа 20 секунд;
2. Диспетчер учетных веб-записей опосредованно (через RPC и службу DcomLaunch) вызывает:
   
   Цитата:

   BackgroundTaskHost.exe -ServerName:BackgroundTaskHost.WebAccountProvider

   и ждет ответа 20 секунд;
3. BackgroundTaskHost.exe обращается к прокси-серверу:
   
   Цитата:

   BackgroundTaskHost.exe 11632 TCP Send crm-manager.omega-spb.local:13922 -> control.omega-spb.local:3128 SUCCESS

   и зависает на 20 секунд, далее - ошибка.

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

Чунга, да Exchange :)))

Самое интересно что проверка автодискавери на компе пролетает практически моментально и без ошибок. После запуска почты, делаю на значке почты в нижнем правом углу ctrl+ПКМ и выбираю проверку автонастройки почты.

anatoly_neo, журналы на прокси смотрели?

Petya V4sechkin,
прокси показывает попытки коннекта к:
https://login.windows.net:443/ HTTP/1.0" 200 7697
https://login.microsoftonline.com:443/ HTTP/1.0" 200 5974
https://outlook.office365.com:443/ HTTP/1.0" 200 0
к нашему центральному серверу Exchange
https://mobile.pipe.aria.microsoft.com:443/ HTTP/1.0" 200 6840
https://login.windows.net:443/ HTTP/1.0" 200 6544
https://odc.officeapps.live.com:443/ HTTP/1.0" 200 8669

судя по запросам между запросом на подключение к https://odc.officeapps.live.com:443/ HTTP/1.0" 200 8669 и https://login.windows.net:443/ HTTP/1.0" 200 6744 проходит около 30 секунд , видимо Outlook чего-то ждёт...
Доступ к этим доменам открыт. Но то открыто у меня, а есть ещё прокся выше, а вот там может быть и прикрыто. буду в понедельник смотреть, возможно в этом косяк.

Пошерстив логи на прокси сервере, подкрутив немного настройки на прокси (добавил запись в ДНС о том куда надо запрос про внутренний сервак чунги переадресовать, на внутренний ДНС , а так же добавив в белый список указанные ранее адреса мелкософта) и настройки браузера в части прокси (добавив внутренний сервак чунги в исключения прокси) удалось таки заставить Outlook запускаться идеально быстро, секунд за 5.
Petya V4sechkin, ОГРОМНОЕ спасибище за помощь, эпопея с попыткой понять что происходит растянулась надолго (с моей стороны, ещё до обращения на форум), а решение оказалось элементарным и в то же время не очень, ибо остальные ПК работают на таких же настройках и проблем с почтой не наблюдается (проблемы начали появляться только с ново настроенными)...