Microsoft Teams Blog articles ... Заметка

Microsoft Teams Blog articles на русском

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

Трэд заметок

Последнее обновление Mixed Reality Link улучшает соединение между вашей гарнитурой смешанной реальности и ПК с Windows. Теперь ваша гарнитура может функционировать как микрофон для приложений Windows. Это обеспечивает более естественное общение на совещаниях, в играх и чатах непосредственно с устройства, которое вы носите. Кроме того, фронтальная камера гарнитуры может использоваться приложениями Windows для демонстрации вашей точки зрения. Это означает, что вы можете показывать другим то, что видите, в режиме реального времени. Пользователи Meta Quest теперь могут использовать Avatar Camera, чтобы появляться в качестве своего аватара в Windows. Эта функция позволяет пользователям сохранять свое присутствие в виртуальных взаимодействиях без необходимости использования традиционной веб-камеры. Эти новые возможности доступны в Mixed Reality Link версии 26.9105.9070.0 и новее. Просто подключите гарнитуру через Mixed Reality Link, чтобы активировать эти новые источники микрофона и камеры в Windows. Эти источники включают микрофон, камеру сквозного обзора и камеру аватара для пользователей Meta. Вы можете выбрать эти устройства в предпочитаемых вами приложениях.
Я тестирую очень строгую политику защиты приложений Intune для Microsoft Word на iOS. Политика успешно блокирует такие действия, как сохранение корпоративных данных в неуправляемых расположениях, копирование/вставку, снимки экрана, печать и передачу данных в другие приложения. Однако пользователи по-прежнему могут открывать Word, просматривать нативные файлы iOS, открывать личные/локальные документы и изменять их. Является ли это ожидаемым поведением? Другими словами, защищают ли политики защиты приложений только организационные данные, разрешая при этом доступ к личным файлам, хранящимся на устройстве? Нашел ли кто-нибудь способ запретить Word просматривать или открывать локальные файлы через приложение "Файлы" iOS, будь то с помощью политик защиты приложений, политик конфигурации приложений или ограничений MDM? Заранее спасибо за любые сведения.
Microsoft Foundry улучшила взаимодействие между агентами благодаря общедоступности инструмента A2A и конечных точек A2A, поддерживающих версию протокола 1.0. Существующие интеграции по-прежнему могут использовать старый инструмент a2a_preview и версию протокола 0.3. Хостируемые агенты могут получить доступ к инструментам A2A через Foundry Toolboxes, предоставляемые через MCP. Эти функции позволяют создавать многоагентные системы, в которых агенты специализируются, делятся навыками и безопасно сотрудничают между границами. Стандартизированный протокол A2A устраняет необходимость в пользовательских API или тесно связанных логиках оркестрации. Агенты теперь могут запрашивать помощь у других без глубокого знания деталей их реализации, используя карточки агентов для обнаружения и протокол A2A для связи. Для хостируемых Microsoft Foundry конечных точек A2A обнаружение и доступ к конечным точкам защищены аутентификацией Microsoft Entra ID. Внешний агент может обнаружить и вызвать хостируемый Microsoft Foundry агент, представленный как конечная точка A2A, взаимодействуя с его карточкой агента и используя протокол A2A. И наоборот, хостируемый Microsoft Foundry агент может использовать инструмент A2A для подключения к другому совместимому с A2A агенту, настраивая это через соединение проекта RemoteA2A. Хостируемые агенты интегрируют возможности A2A, подключая Foundry Toolbox, который затем вызывает A2A Toolbox Tool и соединение RemoteA2A для взаимодействия с удаленными агентами. Аутентификация является критически важным архитектурным решением, с такими вариантами, как none, custom-keys, oauth2, user-entra-token, project-managed-identity и agentic-identity, доступными для соединений RemoteA2A, в то время как входящие конечные точки A2A строго требуют аутентификации Microsoft Entra ID. Чтобы представить хостируемый Microsoft Foundry агент как конечную точку A2A, необходимо настроить карточку агента, описывающую возможности, и протокол A2A на конечной точке агента.
Компания, участвующая в программе спонсорства Azure, ошибочно полагала, что использование моделей Claude через Azure AI Foundry покрывается их спонсорскими кредитами. Они обнаружили, что Claude считается платной услугой Azure Marketplace, которая явно исключена из спонсорства. Это недоразумение привело к прямым начислениям на сумму около 22 000 канадских долларов всего за три дня. Компания утверждает, что при развертывании не получила четких предупреждений о том, что Claude повлечет за собой отдельные расходы Marketplace или что их спонсорство не будет применяться. Они также упоминают, что их настроенный бюджет не выдал своевременного или значимого предупреждения об этих неожиданных расходах. Обнаружение этих расходов было почти случайным, что вызывает опасения по поводу того, насколько выше могли бы быть затраты. Их попытки решить эту проблему через службу поддержки Microsoft оказались разочаровывающими: возникли трудности с созданием соответствующих заявок и получением общих или бесполезных автоматических ответов. Некоторые рекомендованные инструменты управления затратами также, как сообщается, недоступны или ограничены в рамках их устаревшей подписки на спонсорство. Одна заявка в службу поддержки была закрыта без решения, что усугубило их опасения. Компания срочно ищет возможность эскалации этого спора по выставлению счетов за пределы стандартной поддержки спонсорства, чтобы связаться с лицом, уполномоченным рассмотреть обстоятельства. Они ищут рекомендации о том, как оспорить расходы Marketplace в исключительных ситуациях и эскалировать нерешенные случаи поддержки. В конечном итоге они желают пересмотра их ситуации, подчеркивая, что они не пытаются уклониться от законных расходов, а ищут помощи из-за отсутствия четких предупреждений и сложного опыта поддержки.
Выпущена предварительная версия Windows Admin Center 2610, объединяющая режим администрирования (aMode) и режим виртуализации (vMode) в единый установщик для упрощенного развертывания. Этот унифицированный установщик оптимизирует настройку и снижает административные расходы, позволяя пользователям выбирать только один режим на установку. Новые функции в vMode включают упрощенное подключение к Azure Arc благодаря переработанному опыту регистрации, который требует меньше разрешений и не требует согласия администратора на уровне клиента. Обновление также представляет встроенные возможности резервного копирования и восстановления для сред vMode, а также управление жизненным циклом сертификатов. Для производственных сред vMode теперь поддерживает управление сертификатами через службы сертификатов Active Directory, улучшая управление и масштабируемость. Улучшения сетевых функций в vMode обеспечивают лучшую видимость намерений, возможность обновления состояния сети без перезапуска рабочих процессов и поддержку переопределения VLAN хранилища. Инструмент преобразования виртуальных машин был удален из-за изменений, влияющих на требуемый пакет VMware VDDK, с рекомендацией альтернатив, таких как System Center Virtual Machine Manager и Azure Migrate. Возможности живой миграции теперь интегрированы в инструмент виртуальных машин для управляемых vMode машин, обеспечивая бесшовное перемещение виртуальных машин с минимальным простоем. SDK Windows Admin Center обновлен до версии 6.0.0, добавлена поддержка создания и тестирования расширений на основе React. Реализован ряд ключевых исправлений ошибок, включая устранение сбоя установщика и обеспечение доступности инструмента GPU в vMode.
Нативные службы Azure составляют основу готовой к FinOps посадочной зоны, предлагая надежное управление, мониторинг и контроль затрат. По мере расширения экосистемы Azure за пределы подписок и бизнес-подразделений возникает пробел в понимании конкретной ответственности за приложения, их зависимостей и реальных затрат. Именно здесь дополнительные платформы управления могут дополнять, а не заменять, нативные возможности. Эти платформы улучшают основу Azure, предоставляя мониторинг, ориентированный на приложения, а не только на ресурсы. Они консолидируют мониторинг по многочисленным подпискам и регионам для упрощения устранения неполадок. Системы оповещения могут стать более действенными за счет сопоставления оповещений с конкретными приложениями и их влиянием. Автоматизированное исправление детерминированных проблем становится более эффективным благодаря этим платформам. Для FinOps они обеспечивают более глубокий анализ затрат, распределяя расходы по бизнес-подразделениям и приложениям. Становится возможным обнаружение аномалий в моделях расходов, оповещая заинтересованные стороны о необычных отклонениях. Платформы также могут выявлять неиспользуемые ресурсы для оптимизации и экономии затрат. Еще одним преимуществом является поддержание актуальной документации, отражающей реальную среду Azure. Дополнительный операционный уровень, такой как Turbo360, находится над основой Azure, улучшая мониторинг приложений, аналитику FinOps и автоматизацию операций. Такие платформы ценны для больших, сложных сред Azure с большим количеством ресурсов, множеством приложений и значительным объемом оповещений. Решение о внедрении дополнительной платформы должно основываться на четких операционных потребностях и измеримых бизнес-результатах, которые нативные службы не могут эффективно решить.
CdXz5zHNQW_aOH5aQ1ZRW.png
Релиз mssql-django 2.0 представляет поддержку нового драйвера Microsoft mssql-python наряду с существующим методом pyodbc. Это позволяет пользователям выбирать предпочтительный драйвер на основе псевдонима базы данных в настройках Django. Новый драйвер mssql-python упрощает развертывание, включая необходимый драйвер ODBC, устраняя отдельный шаг установки. Он обрабатывает различные функции, такие как аутентификация, пулинг и значения datetimeoffset. Однако этот драйвер имеет некоторые отличия, игнорируя определенные специфичные для pyodbc опции, такие как host_is_server и MARS. Пользователям следует оставаться на pyodbc, если они полагаются на именованные DSN, FreeTDS, MARS или Always Encrypted. Релиз обновляет поддерживаемые версии Python, Django и SQL Server. Старые версии Python и Django больше официально не поддерживаются. Исправлен ряд ошибок, включая проблемы с настройками MARS, подстановочными знаками в скобках в выражениях F(), цитированием имен схем в inspectdb и подключением к localhost. Зависимость от pytz удалена, вместо нее используется модуль zoneinfo из стандартной библиотеки для обработки часовых поясов. Предварительным условием для обновления до версии 2.0 является наличие совместимого дистрибутива mssql-python в операционной системе.
Малые и средние предприятия (МСП) осознают важность ИИ, но нуждаются в управляемом, низкорисковом способе его внедрения. Copilot в 30 предлагает бесплатную 30-дневную пробную версию для 25 пользователей Microsoft 365 Copilot Business, предоставляемую партнерами. Публикация этого предложения в Microsoft Marketplace создает масштабируемую витрину для охвата клиентов из сегмента МСП. Такой структурированный подход превращает интерес к ИИ в долгосрочные отношения с клиентами и постоянные управляемые услуги. Сегмент МСП, с высоким спросом и ограниченными внутренними возможностями в области ИИ, идеально подходит для этого повторяемого решения, управляемого партнерами. Microsoft 365 Copilot Business предоставляет доступный инструмент ИИ, интегрированный в привычные приложения. 30-дневная пробная версия, управляемая партнерами, помогает пользователям ощутить реальную ценность. Партнеры играют ключевую роль в превращении этой пробной версии в устойчивую привычку использования ИИ. Предложение включает конкретные этапы: идентификация, планирование, активация, использование и конверсия. Доход генерируется не только от пробной версии, но и от последующих платных подписок и управляемых услуг. Партнеры могут использовать стимулы и финансирование от Microsoft для поддержки этого процесса. Долгосрочное взаимодействие сосредоточено на управлении внедрением, расширении лицензий, разработке агентов и обеспечении безопасности. Это приводит к регулярным услугам, основанным на результатах, которые позиционируют партнеров как незаменимых консультантов по ИИ.
Розничная организация использует агента Copilot Studio с Fabric IQ, Ontology и ERP MCP для анализа данных о прошлых промо-продажах из сторонних систем и D365 Finance and Operations. Эта система помогает выявлять наиболее эффективные магазины, успешные мероприятия по продажам и клиентские профили, связывая клиентов с магазинами по городу, а мероприятия по продажам — с продуктами и магазинами. В настоящее время ритейлер стремится решить новые задачи: выявление рисков закупок, влияющих на промо-продажи, и определение оптимального распределения маркетинговых расходов по городам. Для удовлетворения этих новых потребностей предлагается агент Foundry, использующий Foundry IQ, Fabric IQ и Web IQ в качестве источников знаний. Foundry IQ действует как уровень логики и оркестрации, объединяя информацию из различных источников, включая Fabric IQ, Work IQ, Web IQ, SharePoint и пользовательские агенты, с поддержкой Azure AI Search для получения точных результатов.Решение требует нескольких предварительных условий, включая источники данных из сторонних систем (продукты, магазины, мероприятия по продажам) и D365 F&O (данные о клиентах), с установленными связями, такими как соответствие клиентов магазинам по городу и ассоциации мероприятий по продажам с продуктами и магазинами. Политики маркетинга по странам хранятся в SharePoint, а Web IQ настроен для получения информации в реальном времени о новостях поставщиков, рыночных сбоях и геополитических событиях. Данные Finance and Operations подключены к Fabric Lakehouse, а другие данные загружаются в Lakehouse, который затем формирует Fabric Ontology, объединяющую данные о клиентах, магазинах, продуктах и мероприятиях. Также необходим проект Azure Foundry с развертыванием LLM и соответствующей аутентификацией.Архитектурный шаблон включает интеграцию этих компонентов для обеспечения логики агента. Конфигурация включает настройку службы Azure Search, создание агента на портале Azure Foundry с ERP MCP в качестве инструмента и настройку знаний Foundry IQ для включения Fabric IQ, Web и SharePoint. Эта интегрированная база знаний затем используется агентом Retail Growth Intelligence. Агент может быть опубликован в различных каналах, таких как M365, Teams или Copilot Studio.Агент может отвечать на сложные вопросы, такие как "Существуют ли риски, связанные со сроками закупок или другие риски, влияющие на промо-продажи?", объединяя Fabric IQ для понимания взаимосвязей сущностей, D365 F&O через ERP MCP для оперативных данных о закупках, SharePoint для проверки политик и Foundry IQ/Web Intelligence для внешних рыночных рисков. Этот процесс включает подвопросы, охватывающие предстоящие мероприятия по продажам, наличие продуктов на складе через данные о заказах на покупку и инвентаризации, а также соответствие политикам. Такой подход преобразует разрозненную информацию в унифицированную поддержку принятия решений. Он обеспечивает более быстрые, качественные и масштабируемые решения на основе ИИ, что приводит к проактивному выявлению рисков и улучшению бизнес-преимуществ за счет корреляции операционных фактов с бизнес-контекстом и внешними сигналами.
Модели машинного обучения со временем деградируют без оценки, что является проблемой, часто упускаемой из виду для разговорных агентов данных. Genie Ontology, в частности через Genie Agent Benchmarks, решает эту проблему путем непрерывной оценки и улучшения агентов. Бенчмарки включают изолированные диалоги, каждый из которых оценивается в одном из двух режимов в зависимости от типа вопроса. Режим чата сравнивает сгенерированный агентом SQL или его результат с "эталонным" ответом, с объективными правилами для "хороших" и "плохих" результатов. Режим агента предназначен для многошаговых отчетов с текстовым обоснованием, где судья LLM оценивает ответ на основе необязательной заметки об оценке. Ключевой особенностью дизайна является способность режима чата вознаграждать допустимые вариации, одновременно отмечая структурные ошибки, что способствует доверию к бенчмарку. Лучшая практика рекомендует регистрировать две-четыре вариации формулировок для каждого бизнес-вопроса, чтобы обеспечить всестороннее тестирование. После запуска бенчмарка Genie Code анализирует результаты, предлагая корректировки инструкций или контекста для устранения выявленных пробелов. Этот "пакетный обзор" также применяется к реальным данным использования, позволяя проактивно решать проблемы. Однако человеческий обзор имеет решающее значение, поскольку отзывы пользователей не изменяют автоматически поведение агента. Качество эталонного SQL также критически важно, и инструмент не хранит внутренне долгосрочные тенденции точности. Инвестирование в бенчмарки с первого дня необходимо для эффективной проверки изменений и обеспечения постоянной надежности агента.
В этой статье представлен надежный процесс управления образами виртуальных машин предприятия, отказывающийся от ручных методов, вызывающих несоответствия. Рекомендуемый подход рассматривает каждый образ как версионированный артефакт сборки, начиная с контролируемого источника и проходя детерминированную конфигурацию. Этот процесс включает использование HashiCorp Packer для параметризованных сборок и Azure DevOps для оркестрации. Основные этапы включают сборку образа, публикацию его в Azure Compute Gallery, проверку опубликованной версии с помощью временной виртуальной машины и получение доказательств для отслеживаемого продвижения.Решение подчеркивает единую, воспроизводимую сборку Packer, чтобы избежать сложностей многоуровневых конвейеров. Значения, специфичные для среды, хранятся отдельно как параметры конвейера, обеспечивая гибкость. Конфигурация Packer определяет сборщик и детерминированную последовательность предоставления ресурсов, обеспечивая согласованность. Важно отметить, что в статье подчеркивается необходимость проверки опубликованной версии образа, а не только виртуальной машины сборки, путем развертывания временной виртуальной машины и выполнения удаленных проверок.Покрытие проверки включает проверки базовой конфигурации ОС, времени выполнения, пакетов, служб и доверия, а результаты публикуются в виде доказательств. Эти доказательства, наряду с журналами сборки и результатами сканирования, коррелируются с выполнением конвейера для полной отслеживаемости. Продвижение контролируется, гарантируя, что продвигается точно та же проверенная версия образа, а не пересобирается.Интегрированы обработка сбоев и очистка, гарантирующие удаление временных ресурсов. Производственные соображения включают выпускные ворота для этапов сборки, функциональной проверки, безопасности и продвижения, поддерживаемые стабильным контрактом на проверку. Конвейер образов завершается версионированным, проверенным артефактом галереи, на который потребители могут ссылаться для контролируемого развертывания. В конечном итоге, рассмотрение процесса создания образов как проблемы доставки программного обеспечения, с версионированными выходными данными и независимой проверкой, упрощает операции.