Microsoft меняет адрес веб-клиента Teams. В течение сентября 2026 года пользователи, открывающие teams.microsoft.com, могут быть перенаправлены на teams.cloud.microsoft. Microsoft описывает это как смену домена, а не миграцию функциональности: существующие ссылки и закладки должны продолжить работать, а конечным пользователям не потребуется устанавливать новый клиент.

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

На практике всё зависит от того, через какие системы проходит запрос. Корпоративный прокси, защищённый веб-шлюз, политика DNS, список разрешённых сайтов в браузере, политика безопасности содержимого, манифест приложения или контроль удалённого доступа могут обработать новый адрес иначе, чем старый. В таких средах перенаправление не становится автоматически безобидным. Браузер должен разрешить имя и подключиться к целевому узлу, средства защиты — пропустить запрос, а встроенные приложения Teams — распознать новый источник.

Непосредственный совет прост: считайте teams.cloud.microsoft рабочей точкой доступа, проверьте данные об оконечных точках Microsoft 365, которыми пользуется ваша организация, и протестируйте весь веб-сценарий до того, как пользователи обнаружат изменение через неудачный вход или пустую вкладку. Более общий вывод касается не только Teams. Изменения URL в SaaS-сервисах должны попадать в управление оконечными точками и контроль изменений даже тогда, когда поставщик утверждает, что функциональность продукта не меняется.

Что именно меняет Microsoft

В уведомлении Message Center MC1465764 говорится, что к сентябрю 2026 года пользователи веб-версии Teams будут перенаправляться с teams.microsoft.com на teams.cloud.microsoft. Уведомление помечает изменение как крупное и указывает на необходимость действий со стороны администраторов. Целевой адрес относится к более широкой группе доменов cloud.microsoft, которую Microsoft ввела для аутентифицированных пользовательских интерфейсов Microsoft 365.

Миграция не представлена как новый клиент Teams или новая система учётных записей. Человек, работающий в браузере, должен по-прежнему попадать в тот же сервис с теми же чатами, собраниями, файлами и контекстом организации. Видимая разница — адрес в строке браузера и сетевое или веб-прикладное поведение, которое этот адрес вызывает.

Microsoft сообщает, что старый URL будет перенаправлять пользователя, а существующие ссылки продолжат работать. Для обычного пользователя это снижает вероятность сбоя, однако не отменяет административное тестирование. Закладка может без проблем пройти HTTP-перенаправление, тогда как строго настроенный прокси способен оценить два имени узлов по отдельности. Браузер может загрузить страницу, но встроенная вкладка завершится ошибкой, если её политика frame-ancestors не обновлена. Межсетевой экран может разрешать teams.microsoft.com и отклонять *.cloud.microsoft.

В том же уведомлении Message Center сказано, что временный административный элемент управления позволит отключить перенаправление, но эта возможность завершится 31 декабря 2026 года. Следовательно, это средство для переходного периода, а не постоянная операционная модель. Организациям, которые им воспользуются, следует зафиксировать исключение, назначить владельца и заранее спланировать его удаление.

В общедоступной документации Microsoft по оконечным точкам уже указаны *.teams.microsoft.com и *.teams.cloud.microsoft, а также teams.microsoft.com и teams.cloud.microsoft. В той же документации *.cloud.microsoft назван обязательной унифицированной оконечной точкой для аутентифицированных интерфейсов Microsoft 365. Практический смысл существенен: организации нужно обновить процесс, в котором хранится эталонный список разрешённых оконечных точек, а не просто добавить одно имя в одно правило межсетевого экрана.

Почему перенаправление может стать отказом в обслуживании

Перенаправление проходит через несколько контрольных точек. Каждая из них способна породить свой симптом, хотя для пользователя это будет выглядеть как одно сообщение: Teams не работает. При этом сам сервис Microsoft может оставаться исправным.

Межсетевые экраны и защищённые веб-шлюзы

В традиционных списках разрешений часто указаны конкретные имена узлов. Если политика пропускает teams.microsoft.com, но не teams.cloud.microsoft, первый запрос может завершиться успешно, а перенаправленный — быть заблокирован. В зависимости от шлюза пользователь увидит страницу отказа в доступе, тайм-аут, цикл аутентификации или неполную оболочку приложения.

Некоторые организации используют фильтрацию по категориям, проверку TLS или явную маршрутизацию через прокси. Такие средства могут опираться на имена в сертификатах, категории URL или правила, написанные вокруг старого домена. Новый узел необходимо оценить в рамках той же предполагаемой политики. Добавление широкого шаблона без проверки того, как шлюз его обрабатывает, создаёт ненужную область доступа; отказ от шаблона без понимания рекомендаций Microsoft делает эксплуатацию хрупкой. Конкретное решение зависит от модели контроля организации, но оно должно быть осознанным и документированным.

DNS и поведение раздельных сетей

Новое имя также попадает в процессы DNS. Внутренние резолверы, службы фильтрации, защищённые DNS-продукты и клиенты удалённого доступа могут применить к недавно обнаруженному домену другую политику. Проверьте офисные сети, устройства с подключённым VPN, сценарии работы из дома и все управляемые среды виртуальных рабочих столов. Успешная проверка на ноутбуке администратора не доказывает, что каждый путь выхода в интернет поведёт себя так же.

Не прописывайте для этого изменения фиксированный IP-адрес. Рекомендации Microsoft по оконечным точкам сформулированы через домены сервисов и опубликованные адресные данные, а облачные службы могут менять лежащую под ними инфраструктуру. Обход на основе IP способен перестать работать во время обычного изменения сервиса и обойти смысл правил, построенных на именах узлов.

Доступ к Teams через веб зависит не только от достижимости сети, но и от поведения браузера. В руководстве Microsoft по устранению проблем со входом в Teams *.cloud.microsoft относится к доменам, которые могут потребовать добавления в доверенные, если браузерные ограничения блокируют cookie или ограничивают список доверенных сайтов. Организациям, которые запрещают сторонние cookie, принудительно задают списки сайтов или распространяют групповые политики, следует проверить вход, запуск собрания и навигацию после перенаправления.

Исключение для домена нужно ограничить необходимыми сервисами Microsoft и проводить через тот же процесс рассмотрения, что и прочие исключения, связанные с аутентификацией. Не отключайте глобально защиту конфиденциальности браузера только ради успешной проверки. Сначала выясните, связана ли проблема с областью cookie, политикой доверенных сайтов, проверкой TLS, правилом прокси или заблокированной оконечной точкой.

Встроенные приложения и вкладки Teams

Teams одновременно является хостом для приложений. Пользовательская вкладка, внутрикорпоративный инструмент или приложение партнёра может загружаться внутри веб-клиента Teams, а не как отдельная страница верхнего уровня. В этом случае новый узел меняет браузерный origin и может обнаружить предположения, которые оставались незаметными при старом адресе.

В руководстве Microsoft для разработчиков Teams сказано, что владельцам приложений следует обновить библиотеку Teams JavaScript до версии 2.19.0 или новее и инициализировать приложение для нового хоста. Там же указано, что приложения, использующие заголовки Content Security Policy, должны включить *.cloud.microsoft в директиву frame-ancestors, сохранив существующие значения для обратной совместимости на время миграции.

Это не повод без разбора менять все заголовки безопасности. Это повод сопоставить заголовок с действительным списком поддерживаемых хостов, проверить приложение в веб-клиенте Teams и убедиться, что проверка origin, записи validDomains, настройки cookie и обработка postMessage по-прежнему соответствуют задуманному сценарию.

Типичный сбой выглядит как частичный успех: оболочка Teams загружается, но вкладка показывает пустой фрейм; вкладка открывается, но выбор файла не работает; либо после аутентификации приложение возвращает пользователя без пригодной сессии. Прежде чем менять код, зафиксируйте узел, видимый в браузере, и узел, который появляется в сетевых трассировках.

Кого затрагивает изменение

В первую очередь изменение касается организаций, где Teams используется в браузере, а исходящий доступ контролируется межсетевыми экранами, прокси, защищёнными веб-шлюзами, DNS-фильтрами или управляемой политикой браузера. Люди, работающие только в настольном или мобильном клиенте, заметят его меньше, хотя ссылки, передача управления аутентификацией и встроенные сценарии всё равно могут задействовать браузерные компоненты.

Вторая группа — владельцы приложений Teams. Сюда входят внутренние разработчики, поставщики программного обеспечения, команды интранета и подразделения, поддерживающие вкладки, расширения сообщений, сайты, встроенные в Teams, или интеграции, которые проверяют происхождение Teams. Их риск не ограничивается самим первым перенаправлением. Новый узел может повлиять на политики фреймов, проверки origin, предположения о redirect URI, атрибуты cookie, фильтры телеметрии и инструкции поддержки.

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

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

Какие сведения об оконечных точках важны

В документации Microsoft по URL и IP-адресам Microsoft 365 сказано, что обязательные оконечные точки должны быть доступны; *.cloud.microsoft указана как обязательное назначение унифицированного домена по TCP 443 и UDP 443. В разделе Teams перечислены *.teams.cloud.microsoft, *.teams.microsoft.com, teams.cloud.microsoft и teams.microsoft.com, с TCP 443 и 80, а также UDP 443.

Эти записи полезнее, чем список из сообщения на форуме: Microsoft обновляет данные по мере изменения сервисов. В документации сказано, что сведения об оконечных точках обычно публикуются заранее, но в течение месяца обновления также могут появляться из-за эскалаций поддержки, инцидентов безопасности или других срочных операционных обстоятельств. Это весомый аргумент в пользу автоматизации загрузки списка в тех средствах защиты, которые такую интеграцию поддерживают.

Одновременно важно учитывать категории оконечных точек. Microsoft различает обязательные, необязательные и используемые по умолчанию назначения и объясняет, что функция может зависеть от оконечных точек из нескольких групп рабочих нагрузок. Команда, которая просто ищет слово Teams в статическом списке, может пропустить распространённый адрес аутентификации или содержимого, необходимый для полного сценария.

Безопасная рабочая последовательность такова: сопоставить актуальные данные Microsoft с реальными уровнями контроля в организации, а затем проверить результат. Не считайте, что один список разрешений на периметровом межсетевом экране отражает всю действующую политику. Брокер облачного доступа, агент на конечном устройстве, конфигурация браузера, частная DNS-зона или правило раздельной маршрутизации VPN всё ещё могут заблокировать новый узел.

Практический план проверки

1. Определите реальных пользователей и пути доступа

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

Зафиксируйте средства контроля, применяемые на каждом пути: фильтрацию DNS, прокси, проверку TLS, межсетевой экран, защищённый веб-шлюз, политику браузера, защиту конечного устройства и политику условного доступа для идентификации. Такая карта позднее поможет отличить проблему сервиса от локального ограничения.

2. Проверьте источник эталонного списка оконечных точек

Используйте актуальную документацию Microsoft по оконечным точкам Microsoft 365 и, если возможно, её загружаемые данные или веб-сервис, а не таблицу, которую кто-то вручную поддерживал локально. Убедитесь, что обязательные записи унифицированного домена и записи Teams представлены именно в тех системах, которые реально применяют ограничения доступа.

Если организация намеренно разрешает только отдельные FQDN, вместе с владельцем безопасности решите, достаточно ли teams.cloud.microsoft для текущего перенаправления веб-клиента Teams или для более широкого использования Microsoft 365 нужен документированный шаблон. Шаблон упрощает обслуживание, а отдельные имена дают более узкую область доступа, но требуют более частого сопровождения. Выбор должен быть объяснимым и зафиксированным.

3. Проверьте само перенаправление

С каждого представительного сетевого пути откройте старый адрес Teams и проследите всю цепочку. Убедитесь, что запрос доходит до teams.cloud.microsoft, сертификат принимается, аутентификация завершается и приложение полностью загружает оболочку. Проверьте обычную пользовательскую учётную запись и административную; у привилегированных аккаунтов могут быть другие политики и сохранённое состояние.

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

Очищайте кэш данных сайта только после фиксации первого результата. Очистка может скрыть воспроизводимую проблему миграции или, наоборот, создать ложный сбой, которого обычные пользователи не увидят. Проведите хотя бы одну проверку в чистом профиле и одну — в управляемом рабочем профиле.

4. Проверяйте действия пользователя, а не только стартовую страницу

Зелёный экран входа ничего не гарантирует. Проверьте действия, важные для организации: открытие чата, подключение к собранию, запуск звонка, если он разрешён, открытие общего файла, переключение между арендаторами, если оно применяется, загрузку пользовательской вкладки и работу каждой одобренной интеграции Teams. Сравните прямую закладку браузера со ссылкой, полученной по электронной почте или в приглашении календаря.

Для собраний проверьте путь от ссылки календаря: браузер может пройти через дополнительные этапы перенаправления и аутентификации. Для файлов откройте и, если это важно для рабочего процесса, отредактируйте представительный документ. Для пользовательских приложений проверьте каждую критичную вкладку и путь возврата после входа.

5. Проверьте политики встроенных приложений

Владельцам приложений следует поискать в исходном коде и конфигурации жёстко заданные ссылки на teams.microsoft.com, прямые сравнения origin, значения CSP frame-ancestors, списки доверенных доменов, redirect URI, предположения о домене cookie и фильтры телеметрии. Поиск должен охватывать конфигурацию развёртывания и документацию, а не только код приложения.

Следуйте рекомендациям Microsoft для приложений Teams относительно версии TeamsJS и поведения инициализации. Сохраняйте старые значения, если нужна обратная совместимость, и добавляйте новый узел в соответствии с моделью безопасности приложения. Не заменяйте старые значения вслепую: пользователи ещё могут приходить через старый URL, а другие узлы Microsoft 365 могут оставаться поддерживаемыми.

После изменения заголовков или манифестов протестируйте каждый поддерживаемый контекст размещения. CSP, работающая в отдельной вкладке браузера, всё ещё может отклонять встроенный фрейм. И наоборот, слишком разрешающий тестовый заголовок способен скрыть, что в рабочей среде ответ формирует другой обратный прокси или CDN.

6. Обновите эксплуатационные материалы

Поищите старое имя Teams в статьях службы поддержки, руководствах для новых сотрудников, формах заявок на межсетевой экран, политиках прокси и браузера, проверках мониторинга и инструкциях реагирования на инциденты. В исторических заметках старый URL можно сохранить, но в текущих материалах его следует описывать как источник перенаправления, а не как единственный адрес сервиса.

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

Чего делать не следует

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

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

Не заменяйте правила имён узлов фиксированными IP-адресами. Облачная инфраструктура Microsoft рассчитана на развитие, а обход через IP может устареть или направить трафик неверно.

Не разрешайте любые назначения *.microsoft без рассмотрения. В релевантной документации Microsoft указаны конкретные семейства доменов и категории оконечных точек; расширение доступа сверх бизнес-требования ослабляет ценность самого контроля.

Не считайте ответ HTTP 200 на первой странице доказательством того, что Teams работает. Сбой может произойти после аутентификации, во время API-вызова, при загрузке вкладки или при открытии файла.

Как обращаться с временным исключением

В уведомлении Microsoft указано, что административный элемент управления для отключения перенаправления Teams перестанет действовать 31 декабря 2026 года. Если организация его применяет, у исключения должны быть ясная причина и назначенный владелец. В полезной записи стоит указать затронутого арендатора или группу пользователей, заблокированную зависимость, ответственную прикладную или сетевую команду, дату целевой проверки и дату удаления исключения.

Исключение не должно становиться заменой сопровождению оконечных точек. Если проблема в правиле прокси, исправьте правило прокси. Если причина в CSP пользовательской вкладки, исправьте ответ приложения. Если виновата сторонняя интеграция, запросите у её владельца поддерживаемый путь миграции и зафиксируйте полученный ответ.

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

Почему это изменение инфраструктуры

Поставщик SaaS может поменять имя узла, не меняя пользовательскую функцию. Для клиента, однако, имя узла является частью контракта сервиса, который реализуют сети, браузеры и приложения. Адрес определяет, какое правило политики сработает, какой сертификат будет проверен, какие cookie отправятся, какой origin будет считаться доверенным и по какому имени трафик попадёт в журналы.

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

Это изменение также показывает, как меняется эксплуатация облака. Адреса сервисов больше не являются статичным приложением к документации, которое однажды обновляют при развёртывании. Microsoft сообщает, что её данные об оконечных точках меняются вместе с сервисами и могут обновляться вне обычного графика при особых операционных обстоятельствах. Организации, автоматически потребляющие эти данные, сокращают ручную задержку, но автоматизация всё равно нуждается в проверке: поток может обновить межсетевой экран, пока CSP приложения и инструкция реагирования останутся прежними.

Краткий список проверок на сентябрь

  • Убедитесь, что в организации действительно используется Teams в браузере.
  • Проверьте MC1465764 в центре администрирования Microsoft 365 и определите статус развёртывания для арендатора.
  • Убедитесь, что teams.cloud.microsoft и релевантные оконечные точки *.cloud.microsoft разрешены документированной сетевой политикой.
  • Проверьте офисный, VPN, удалённый, виртуальный и управляемый браузерный пути.
  • Проследите перенаправление и проверьте вход, собрания, файлы и критичные вкладки Teams.
  • Пересмотрите фильтрацию DNS, правила прокси, проверку TLS, доверие браузера и политики cookie.
  • Попросите владельцев приложений проверить TeamsJS, CSP frame-ancestors, валидацию origin, манифесты и redirect URI.
  • Обновите синтетический мониторинг, документацию и инструкции службы поддержки.
  • Зафиксируйте любое временное исключение для перенаправления, назначив владельца и дату удаления до 31 декабря 2026 года.

Веб-миграция Teams будет почти незаметной для неуправляемого браузера и потенциально значимой для корпоративной среды. Правильная реакция — не широкое экстренное изменение правил межсетевого экрана, а короткая проверка на основе фактов по всем реальным путям пользователей и приложений. После этого перенаправление должно стать именно тем, чем его считает Microsoft: изменением адреса, а не изменением доступности.

Источники

Материал подготовлен на основе уведомления Microsoft 365 Message Center MC1465764 о перенаправлении пользователей веб-клиента Teams на teams.cloud.microsoft; документации Microsoft Learn по URL и диапазонам IP-адресов Microsoft 365; руководства Microsoft Learn по требованиям к вкладкам Teams; материала Microsoft Learn об устранении проблем, при которых Teams не загружается; публикации Microsoft Community Hub о едином домене cloud.microsoft; и обсуждения Neowin о проверках, которые ИТ-администраторам следует провести перед изменением.

В исходных материалах указаны следующие публикации: MC1465764 — Teams web client users will be redirected to teams.cloud.microsoft; Microsoft 365 URLs and IP address ranges; Requirements for Building Tabs; Teams doesn't load; Introducing cloud.microsoft: a unified domain for Microsoft 365 apps and services; Microsoft is changing the domain for Teams on the web, IT admins should validate.