Microsoft Teams Blog articles Note

Microsoft Teams Blog articles

Microsoft Teams Blog on TechNet is a dedicated platform for Microsoft Teams covering various topics including upcoming features, product improvements, and best practices to enhance user experience. It contains articles by Microsoft product team members, MVPs, and other experts in the field. The blog posts address different aspects of Microsoft Teams such as configuration, deployment, troubleshoot, user feedback, and shared knowledge.

Thread Of Notes

The article discusses the development of a HelpDesk Copilot, a Contoso IT service desk that utilizes a Microsoft Foundry agent to triage employee questions and provide answers grounded in an IT knowledge base. The system is designed to hand off to humans through a real channel when policy demands it. The architecture consists of three Azure Container Apps, one Foundry Prompt Agent, and an event-driven ticket pipeline. The agent has three capabilities: File Search, create_ticket, and get_ticket_status, which are used to answer employee questions and escalate issues when necessary.The system is built on Azure Container Apps, provisioned entirely with Terraform, and contains zero API keys, with every service-to-service call using Microsoft Entra ID and managed identities. The Foundry account has local key authentication disabled outright. The architecture is designed to be event-driven, with the API publishing ticket events to a Service Bus topic, which are then delivered to a worker through a Dapr subscription. The worker upserts the ticket into Table Storage and posts the payload to a Power Automate HTTP flow, which sends an Adaptive Card to the IT team's Teams channel.The system is designed to be idempotent, with the ticket ID derived deterministically from the conversation ID and subject, ensuring that repeated create_ticket tool calls for the same issue in the same conversation collapse to the same ID instead of creating a duplicate. The system also uses eventual consistency, with the ticket row may not exist for a few seconds while the worker is woken up by KEDA. The architecture is designed to be scalable, with the ability to add new subscriptions to the Service Bus topic without changing the API.The identity model is designed to use Entra ID via DefaultAzureCredential, with each app using a user-assigned managed identity. The API, worker, and frontend each have their own identity, with the API having access to AcrPull, Foundry agent access, Storage Table Data Reader, Key Vault Secrets User, and Service Bus Sender. The worker has access to AcrPull, Storage Table Data Contributor, Key Vault Secrets User, and Service Bus Receiver, while the frontend only has access to AcrPull.The article also discusses the use of Terraform to provision the Azure resources, with the author noting that the obvious-looking resources are not always the correct ones. The author had to use azurerm_cognitive_account to provision the Foundry Agent Service, rather than azapi. The article concludes by noting that the system is designed to be secure, scalable, and event-driven, with a focus on using managed identities and Entra ID to authenticate service-to-service calls.
Managing large device fleets with Microsoft Intune often requires retrieving extensive reporting data, a task ideally suited for the export API. This API facilitates asynchronous export jobs for reports, drastically reducing the number of API calls compared to individual Graph calls. For instance, a nightly job for 50,000 devices, which previously involved 100,000 operational Graph API calls and took 2.5 hours, can now be completed in 15 minutes with only 15 calls using the export API. This significant improvement stems from the export API's ability to generate an entire report server-side, providing a single downloadable file.The old method, using operational Graph APIs, involves enumerating devices and making individual calls for each device's compliance status, leading to frequent throttling, complex threading, and fragility due to numerous failure points. The export API, conversely, follows a simple request-poll-download pattern, eliminating this per-device overhead. The core advantage lies in reducing round-trips rather than data volume, as each API call incurs authentication, TLS setup, and network latency costs. By consolidating data retrieval into a single bulk transfer, the export API minimizes these overheads.This shift delivers substantial benefits for IT administrators, including shorter maintenance windows, reduced code complexity, enhanced reliability, and lower service impact. It also offers scalability, as doubling the device fleet primarily means a larger file download, not an exponential increase in API calls. The output schema remains consistent, ensuring no disruption to downstream systems like dashboards or data warehouses. While the export API is ideal for bulk, scheduled snapshots, operational endpoints are still suitable for real-time, single-device lookups. The key takeaway is to leverage the export API for comprehensive fleet data, transforming a time-consuming process into an efficient, robust operation.
Many organizations struggle with Microsoft 365 Copilot adoption because users are not prompt engineers and find the blank screen intimidating. They often type simple queries, are dissatisfied with the results, and stop using the tool. The solution lies in utilizing organizational prompts, an admin setting that allows you to pre-load a library of ready-to-use prompts for your entire organization.These prompts appear across Copilot Chat, Microsoft Edge, and Teams, providing users with a starting point rather than a blank box. To set this up, navigate to the Microsoft 365 admin center, then Copilot, and finally Prompts. You can add prompts individually or import them in bulk via a CSV template, with a limit of 1,000 published prompts.When creating a prompt, you'll define fields like title, display prompt, the actual prompt text, supported apps, department, task type, and language. Departments are free-text filters for users, and task types are predefined by Microsoft to aid filtering. After publishing, it takes about three hours for prompts to appear in the prompt lab, and you can pin up to four important prompts for quick access.The Analytics tab provides valuable insights into prompt usage, helping you identify effective prompts and areas for improvement. Users access these prompts through the Suggested button, the prompt lab, and autosuggest in the Copilot input box. After enabling organizational prompts, it's crucial to inform users about their existence and provide a channel for them to submit successful prompts for inclusion in the library. This feature offers a significant "quick win" for boosting Copilot adoption by giving users the foundation they need to get started effectively.
Microsoft is presenting new opportunities for partners to expand their security and AI practices in fiscal year 2027. This month's security partner roundup highlights essential updates, incentives, and skilling resources. Key focuses include evolving data security with Microsoft Purview and integrating AI insights with Microsoft Copilot and Agent 365. Partners are encouraged to attend the MCAPS Start for Partners and Partner GTM Kickoff events for FY27 priorities and go-to-market strategies. Important news includes the consolidation of Microsoft Defender for Cloud Apps DLP into Microsoft Purview by December 2026 and the retirement of Microsoft Defender Threat Intelligence as a standalone product on August 1, 2026. New specializations are emerging, such as Agentic Security and Frontier Partner, to recognize AI expertise. Several promotional offers are extended, including the Microsoft Sentinel 50-GB promotion and a 50% discount on Microsoft Purview Suite for Business Premium, both through December 2026. Updated CSP security add-ons for Entra ID P2 and Defender for Office 365 P2 are now available with simplified pricing. Security partner investments are unified under Frontier Accelerate for Security, streamlining incentives and enabling modular envisioning workshops. Partners can access skilling opportunities, including training for Microsoft Agent 365 and new certification paths, with the AZ-500 certification retiring in August 2026. Microsoft Ignite in November will offer further insights into AI innovation and future developments.
Post-Stream Refinement (PSR) for Azure AI Speech has reached general availability (GA), offering highly accurate final transcripts without sacrificing instant streaming results. This technology operates by running a second recognition pass in parallel with streaming, replacing initial segments with more accurate versions upon utterance completion. The GA release introduces crucial production capabilities, including diarization for speaker attribution, phrase lists for domain-specific vocabulary, and expanded support to 19 locales across 22 Azure regions. Existing real-time contracts and partial-result streaming remain unchanged; users simply enable refinement by setting a property on their SpeechConfig.Diarization support in PSR ensures that speaker labels are preserved in the refined transcript, making it ideal for meetings, contact centers, and interviews. Phrase lists allow the recognizer to prioritize specific terms, significantly improving accuracy for product names and specialized vocabulary. Internal testing has shown double-digit relative reductions in word error rate, particularly for long utterances and proper nouns. While partial-result latency is unaffected, the final segment may experience a slight increase due to refinement.PSR is now available in 19 locales, including several Indic languages, and across 22 Azure regions in the Americas, Europe, and Asia Pacific. This technology, already powering Microsoft Teams and Microsoft 365 Copilot, brings a production-grade transcription experience to Azure AI Speech customers. To get started, users need Speech SDK 1.50 or later, a Speech resource in a supported region, and the session locale set on the recognizer.A 'PostRefinement' option needs to be set in the SpeechConfig, and optional phrase lists can be added. For scenarios involving multiple languages or code-switching, a Multilingual PSR public preview is available. However, for a known session locale with phrase lists and diarization, the Monolingual GA path is recommended. This release offers a significant leap in transcription quality for Azure AI Speech applications with a minimal configuration change.
Microsoft is expanding its AI model family to offer customers more choice based on specific workload needs. Developers and enterprises seek models optimized for either high quality or responsiveness and cost-efficiency. Today, Microsoft introduces two new additions: MAI-Image-2.5 Pro and MAI-Voice-2 Flash.MAI-Image-2.5 Pro is a high-fidelity image generation model designed for professional creative workflows requiring visual accuracy and control. It excels in scenarios like campaign asset creation, product photography, and storyboarding where object consistency and adherence to creative intent are crucial. This model prioritizes fidelity over throughput, making it ideal for producing polished, professional assets with minimal editing.MAI-Voice-2 Flash is a new low-latency text-to-speech model built for real-time voice applications where speed is paramount. It offers faster response times and greater cost efficiency in over 15 languages. This model is suited for call center agents, conversational voice assistants, and interactive voice response systems to create more natural and immediate user experiences.The choice between MAI-Image-2.5 Pro and its predecessor, MAI-Image-2.5, depends on the need for maximum fidelity and creative quality versus throughput. Similarly, MAI-Voice-2 Flash is for scenarios prioritizing low latency and responsiveness, whereas MAI-Voice-2 focuses more on voice identity. MAI-Image-2.5 Pro is accessible through Microsoft Foundry, and MAI-Voice-2 Flash is available via Azure Speech.
Azure Logic Apps Consumption Integration Accounts were powered by approximately 60,000 Azure Functions apps running on older runtimes. The team successfully migrated all these applications to the newer Functions v4 runtime without requiring any customer action. This was achieved through a meticulous, multi-stage approach designed to ensure compatibility and minimize disruption.The core strategy involved shadowing, where real production traffic was routed to both the old and new runtimes concurrently. This allowed for direct comparison of every single result without the unproven path affecting customers. A key aspect was establishing a robust parity bar, ensuring that 100% of eligible traffic was analyzed to differentiate genuine bugs from inherently nondeterministic workloads.Any real divergences detected were meticulously fixed before any traffic was shifted. The rollout was progressive and reversible, meaning traffic was gradually moved region by region based on traffic hashing. A crucial feature was the ability to roll back the entire migration through a simple configuration change, taking effect within minutes.The retirement of the old applications was handled with extreme care. The old apps were stopped first, followed by a significant observation period before they were permanently deleted. This phased approach ensured that any unforeseen issues could be addressed without impacting customers.This complex migration was possible because Microsoft owned and operated the underlying compute infrastructure. The durable customer data, such as agreements and schemas, remained untouched, and the actions performed were pure transforms. This control plane allowed for parallel execution and comparison of both runtimes.The primary challenge was not the new runtime itself, but proving its compatibility with the existing customer workloads. The legacy runtimes were nearing end-of-life, posing increasing risks. The move to Azure Functions v4, with its isolated worker model, represented a significant architectural shift.Standard lighter-weight migration options like in-place upgrades or simple deployment slots were deemed insufficient due to the host model change and the scale of the operation across 60,000 applications. The migration ensured no customer-visible disruption, although a small number of customers encountered a brief edge case under heavy load before a rollback was initiated. The team absorbed the complexity to provide a seamless experience for their customers.
Microsoft built a large-scale Microsoft 365 Copilot connector to make internal documentation accessible as grounded context within Copilot experiences. This connector aims to bridge the gap where trusted enterprise knowledge often resides in underutilized portals. The connector's true power lies not in ingestion, but in enabling content availability across various Copilot features like Copilot Chat and Copilot in Microsoft 365 apps. It also empowers users to build custom Copilot Studio agents scoped to the connector's content without additional development effort. Transitioning from a prototype to a production-ready connector revealed critical gaps in tenant configuration, security and compliance readiness, discoverability, and shared throttling limits. Early validation of tenant configuration is essential, addressing issues like cross-tenant data flow and ownership gaps. Security and compliance readiness, including threat modeling and privacy reviews, required significant upfront effort. Content discoverability is a challenge as connector content may not be prioritized over emails and user files by default. Designing for throttling and shared limits is crucial, requiring robust retry logic and monitoring for ingestion slowdowns. The architecture emphasizes separating source content from ingestion compute for easier retries, monitoring, and evolution. Iterative schema design significantly improved retrieval quality, and secure authentication and deployment patterns were implemented for consistency.
Azure DDoS Protection has launched a public preview of a new custom policy feature, offering users more control over attack detection and mitigation. This new capability allows customers to fine-tune mitigation behavior and configure protocol-specific detection thresholds for protected workloads. It addresses the need for organizations with unique traffic characteristics, such as latency-sensitive applications or predictable traffic spikes, to customize protection. Advantages include granular control over TCP, UDP, and TCP SYN traffic thresholds, enabling alignment with anticipated traffic changes during events. The feature maintains flexibility while benefiting from Azure's global-scale mitigation infrastructure and allows per-resource policy management for different environments. Customers also retain full operational visibility through existing Azure Monitor and DDoS Protection telemetry. Deployment and management of custom policies are available through the Azure portal, supporting Standard Load Balancer frontend IP configurations. Current limitations include support only for Standard Load Balancer frontend IPs and no PowerShell support. Users should carefully select thresholds based on anticipated traffic baselines, starting with conservative changes and validating behavior in lower environments. While custom policies disable autotuning for configured protocols, autotuning remains active where no custom threshold is set. This enhancement provides an optional override to Azure DDoS Protection's existing automatic and adaptive engine.
Hosting and hybrid cloud partners are currently navigating significant infrastructure transitions. In a May blog, we explored why changes in virtualization licensing, rising infrastructure costs, and evolving customer expectations are creating both pressure and opportunity for hosting businesses. Now the conversation shifts from understanding the opportunity to taking action. It is about evolution without disruption: preserving what works, modernizing where it matters, and growing into higher-value services with Microsoft Adaptive Cloud. That is why we created the new e-book, Navigating the Next Era of Hosting. It is a practical guide for hosting partners looking to protect margins, retain customer trust, and define a clear modernization path across Azure, hybrid, and AI-ready scenarios. From awareness to actionHosting partners are already fielding more complex customer conversations. Customers want flexibility across on-premises, edge, partner datacenter, and public cloud environments. They want consistent management, built-in security, stronger governance, and clear modernization options without being forced into a single destination or timeline. At the same time, many partners are reevaluating long-standing platform strategies. Licensing changes, evolving commercial models, and rising infrastructure costs are prompting new questions about margin predictability, platform control, and long-term differentiation. This is where action matters. Partners that move early can shape the conversation with customers instead of reacting to it. You can explain what will stay consistent, where modernization can begin, and how customers can retain choice while preparing for what comes next.Continue reading here