Microsoft сдвинула дедлайн по отказу от параметра -Credential в Exchange Online PowerShell с июля на декабрь 2026 года. Для администраторов это не косметическая правка в дорожной карте, а дополнительные месяцы на поиск и переписывание старых скриптов, которые до сих пор заходят в Exchange Online по сохраненным логину и паролю.
О переносе срока сообщает The Register. Речь идет о параметре, который используется при подключении к Exchange Online PowerShell и позволяет передавать учетные данные в явном виде. Подход давно считается плохой практикой: Microsoft последовательно выдавливает парольную аутентификацию из админских сценариев в пользу более безопасных методов. Но между красивой схемой на слайде и реальной инфраструктурой, как обычно, лежат годы накопленной автоматизации.
Изначально Microsoft собиралась убрать -Credential уже в июле 2026 года. Теперь компания говорит о модуле Exchange Online PowerShell, выпущенном начиная с декабря 2026 года: если организация обновится на такую версию и у нее останутся сценарии, завязанные на этот параметр, они просто перестанут работать. Под ударом прежде всего связки с командлетами Connect-ExchangeOnline и Connect-IppsSession. Для администраторов это означает вполне приземленную угрозу: не абстрактное «снижение совместимости», а падение рабочих цепочек, которые могут годами обслуживать рутину без лишнего шума.
Почему это вообще больно, если Microsoft заранее предупреждала? Потому что найти такие зависимости в живой среде бывает неприятно дорого по времени. Скрипты разбросаны по репозиториям, task scheduler, jump host-серверам, CI-пайплайнам и чужим папкам с названиями вроде final_v2_really_final.ps1. Даже если конкретное использование Exchange Online PowerShell обнаружено, дальше начинается менее веселая часть: переписать авторизацию, проверить права, обновить секреты, прогнать тесты и убедиться, что новый способ подключения не ломает давно собранный workflow. И это в лучшем случае. В худшем старый сценарий писал человек, который давно ушел, а документация по нему живет только в памяти коллег.
Microsoft прямо признает, что scripts и automation workflows, использующие -Credential для подключения к Exchange Online или Security & Compliance PowerShell, сломаются после обновления на соответствующую версию модуля, начиная с декабря 2026 года. При этом есть важная деталь: само серверное отключение лежащего под этим механизма аутентификации произойдет позже, в отдельную дату, которую компания пока не назвала. То есть отсрочка двуслойная. Сначала совместимость исчезнет в новых версиях модуля, а затем, на следующем этапе, параметр перестанет работать даже на старых сборках. Для тех, кто любит тактику «не трогай, и оно проживет еще год», это плохая новость: вечного замораживания тут не будет.
Официальное объяснение переноса стандартное для больших вендоров и очень знакомое всем, кто администрирует облака в реальном мире: customer feedback. Иначе говоря, клиенты донесли до Microsoft, что между объявлением политики и ее безболезненным исполнением есть разница. Можно сколько угодно говорить, что парольная аутентификация морально устарела, но если за ней стоят рабочие процессы в почте, комплаенсе, ретеншне или расследовании инцидентов, простое удаление параметра превращается в производственный риск. На этом фоне перенос до конца 2026 года выглядит не уступкой из доброты, а признанием того, что экосистема движется медленнее, чем хотелось бы разработчикам платформы.
Контекст тут тоже показательный. Microsoft уже не первый год вычищает из облачных сервисов старые схемы безопасности и совместимости. Exchange Online регулярно становится площадкой, где админам напоминают: старые версии TLS пора выключать, старые привычки в аутентификации пора выбрасывать, а старые скрипты желательно хотя бы инвентаризировать. Проблема в том, что у корпоративной автоматизации длинная память. Если код один раз встроился в процессы онбординга, почтового администрирования, legal hold или отчетности, он может жить намного дольше, чем рассчитывал его автор. Поэтому каждый такой дедлайн бьет не только по технике, но и по оргструктуре: кто владелец сценария, где лежат секреты, кто подписывает изменения, кто отвечает за регрессию.
Для русскоязычной IT-аудитории новость важна не потому, что кто-то особенно любит параметр -Credential, а потому что она хорошо описывает типичный риск работы с облачными платформами. Даже «небольшая» правка в модуле управления может внезапно ударить по автоматизации, на которой держится рутина целого отдела. Если у компании остались административные сценарии вокруг Microsoft 365, сейчас хороший момент провести ревизию: найти подключения к Exchange Online PowerShell, проверить, где еще используется явная передача логина и пароля, и решить вопрос до того, как обновление приедет в production по расписанию или по привычке. Отсрочка до декабря 2026 года здесь не повод расслабиться, а редкий шанс мигрировать без аварийного окна ночью в пятницу.
Самый интересный вопрос теперь не в том, отключит ли Microsoft старую схему, а в том, сколько еще таких «малозаметных» точек осталось в корпоративной автоматизации. История с Exchange Online показывает простую вещь: крупнейшие облака больше не готовы бесконечно тащить за собой устаревшую аутентификацию, но и клиенты не могут переписать наследие по щелчку. Значит, в ближайшие годы выиграют не те, кто громче говорит о zero trust, а те, кто успевает переводить эту идею из презентаций в рабочие скрипты.