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

Microsoft Foundry has enhanced agent-to-agent collaboration with the general availability of the A2A Tool and A2A endpoints supporting protocol version 1.0. Existing integrations can still use the older a2a_preview tool and protocol version 0.3. Hosted Agents can access A2A tools through Foundry Toolboxes exposed via MCP. These features enable the creation of multi-agent systems where agents specialize, share skills, and cooperate securely across boundaries. A standardized A2A protocol eliminates the need for custom APIs or tightly coupled orchestration logic. Agents can now request assistance from others without intricate knowledge of their implementation details, using agent cards for discovery and the A2A protocol for communication. For Foundry-hosted A2A endpoints, discovery and endpoint access are secured by Microsoft Entra ID authentication. An external agent can discover and invoke a Foundry agent exposed as an A2A endpoint by interacting with its agent card and using the A2A protocol. Conversely, a Foundry agent can utilize the A2A Tool to connect to another A2A-compatible agent, configuring this through a RemoteA2A project connection. Hosted Agents integrate A2A capabilities by attaching a Foundry Toolbox, which then invokes the A2A Toolbox Tool and a RemoteA2A connection to interact with remote agents. Authentication emerges as a critical architectural decision, with options like none, custom-keys, oauth2, user-entra-token, project-managed-identity, and agentic-identity available for RemoteA2A connections, while incoming A2A endpoints strictly enforce Microsoft Entra ID authentication. To expose a Foundry agent as an A2A Endpoint, an agent card describing capabilities and the A2A protocol on the agent endpoint must be configured.
A company using an Azure Sponsorship program mistakenly believed their use of Claude models through Azure AI Foundry was covered by their sponsorship credits. They discovered that Claude is considered an Azure Marketplace charge, which is explicitly excluded from sponsorship. This misunderstanding led to approximately $22,000 CAD in direct charges accumulating within three days. The company states they received no clear warnings during deployment that Claude would incur separate Marketplace costs or that their sponsorship would not apply. They also mention that their configured budget did not provide a timely or meaningful alert about this unexpected spending. The discovery of these charges was almost accidental, raising concerns about how much higher the costs could have become. Their attempts to resolve this through Microsoft support have been frustrating, with difficulties in creating appropriate tickets and receiving generic or unhelpful automated responses. Some recommended cost management tools are also reportedly unavailable or limited under their legacy sponsorship subscription. One support ticket was closed without resolution, exacerbating their concerns. The company is urgently seeking to escalate this billing dispute beyond standard sponsorship support to reach an authority who can review the circumstances. They are looking for guidance on how to dispute Marketplace charges under exceptional situations and escalate unresolved support cases. Ultimately, they wish for a review of their situation, emphasizing they are not trying to evade legitimate costs but are seeking assistance due to a lack of clear warnings and a challenging support experience.
Windows Admin Center has released a preview of version 2610, combining Administration Mode (aMode) and Virtualization Mode (vMode) into a single installer for simplified deployment. This unified installer streamlines setup and reduces administrative overhead while allowing users to select only one mode per installation. New features in vMode include easier Azure Arc onboarding with a redesigned registration experience that requires fewer permissions and no tenant-level admin consent. The update also introduces built-in backup and restore capabilities for vMode environments, along with certificate lifecycle management. For production environments, vMode now supports managing certificates through Active Directory Certificate Services, enhancing governance and scalability. Networking improvements in vMode offer better intent visibility, the ability to refresh networking state without restarting workflows, and storage VLAN override support. The VM Conversion tool has been removed due to changes affecting the required VMware VDDK package, with alternatives like System Center Virtual Machine Manager and Azure Migrate recommended. Live migration capabilities are now integrated into the Virtual Machines tool for vMode managed machines, enabling seamless VM movement with minimal downtime. The Windows Admin Center SDK has been updated to version 6.0.0, adding support for creating and testing React-based extensions. Several key bug fixes have been implemented, including resolving an installer failure and making the GPU tool available in vMode.
Azure's native services form the bedrock of a FinOps-ready landing zone, offering robust governance, monitoring, and cost management. As Azure estates expand across subscriptions and business units, a gap emerges in understanding specific application ownership, dependencies, and true costs. This is where additional management platforms can complement, not replace, native capabilities. These platforms enhance Azure's foundation by providing application-centric monitoring instead of just resource-centric views. They consolidate monitoring across numerous subscriptions and regions for easier troubleshooting. Alerting systems can be made more actionable by correlating alerts with specific applications and their impact. Automated remediation for deterministic problems becomes more streamlined through these platforms. For FinOps, they enable deeper cost analysis, allocating expenses to business units and applications. Anomaly detection in spending patterns becomes possible, alerting stakeholders to unusual deviations. Platforms can also identify under-utilized resources for rightsizing and cost savings. Maintaining up-to-date documentation that reflects the live Azure environment is another benefit. An additional operational layer, like Turbo360, sits above the Azure foundation, enhancing application monitoring, FinOps insights, and operations automation. Such platforms are valuable for large, complex Azure environments with high resource counts, multiple applications, and significant alert volumes. The decision to adopt an additional platform should be driven by clear operational needs and measurable business outcomes that native services cannot efficiently address.
CdXz5zHNQW_aOH5aQ1ZRW.png
A retail organization uses a Copilot Studio agent with Fabric IQ, Ontology, and ERP MCP to analyze past promotional sales data from third-party systems and D365 Finance and Operations. This system helps identify top-performing stores, successful sales events, and customer footprints by linking customers to stores by city and sales events to products and stores. The retailer now seeks to address new challenges: identifying procurement risks impacting promotional sales and determining optimal marketing spend allocation across cities. To meet these new needs, a Foundry agent is proposed, leveraging Foundry IQ, Fabric IQ, and Web IQ as knowledge sources. Foundry IQ acts as the reasoning and orchestration layer, connecting insights from various sources including Fabric IQ, Work IQ, Web IQ, SharePoint, and custom agents, backed by Azure AI Search for accurate results.The solution requires several prerequisites, including data sources from third-party systems (products, stores, sales events) and D365 F&O (customer data), with established relationships like customer-store city alignment and sales event-product-store associations. Country-specific marketing policies are stored in SharePoint, and Web IQ is set up for real-time information on supplier news, market disruptions, and geopolitical events. Finance and Operations data is connected to Fabric Lakehouse, and other data is ingested into the Lakehouse, which then forms a Fabric Ontology combining customer, store, product, and event data. An Azure Foundry project with an LLM deployment and appropriate authentication is also necessary.The architecture pattern involves integrating these components to facilitate the agent's reasoning. The configuration involves setting up an Azure Search service, creating an agent in the Azure Foundry portal with ERP MCP as a tool, and configuring Foundry IQ knowledge to include Fabric IQ, Web, and SharePoint. This integrated knowledge base is then used by the Retail Growth Intelligence agent. The agent can be published to various channels like M365, Teams, or Copilot Studio.The agent can answer complex questions like "Are there procurement timeline or any other risks impacting promotional sales?" by combining Fabric IQ for understanding entity relationships, D365 F&O via ERP MCP for operational procurement data, SharePoint for policy validation, and Foundry IQ/Web Intelligence for external market risks. This process involves sub-questions covering upcoming sales events, product stock availability via purchase orders and inventory data, and policy compliance. This approach transforms disparate information into unified decision support. It enables faster, higher-quality, and scalable AI-driven decisions, leading to proactive risk detection and improved business advantages by correlating operational facts with business context and external signals.
This article outlines a robust process for managing enterprise virtual machine images, moving away from manual methods that cause inconsistencies. The recommended approach treats each image as a versioned build artifact, starting from a controlled source and undergoing deterministic configuration. This process involves using HashiCorp Packer for parameterized builds and Azure DevOps for orchestration. The core steps include building the image, publishing it to Azure Compute Gallery, validating the published version with a temporary virtual machine, and producing evidence for traceable promotion.The solution emphasizes a single, reproducible Packer build to avoid complexities of layered pipelines. Environment-specific values are kept separate as pipeline parameters, allowing for flexibility. The Packer configuration defines the builder and a deterministic provisioning sequence, ensuring consistency. Crucially, the article stresses validating the published image version, not just the build VM, by deploying a temporary VM and running remote checks.Validation coverage includes OS baseline, runtime, package, service, and trust checks, with results published as evidence. This evidence, along with build logs and scan outputs, is correlated with the pipeline run for complete traceability. Promotion is controlled, ensuring that the exact same validated image version is promoted, not rebuilt.Failure handling and cleanup are integrated, ensuring temporary resources are removed. Production considerations include release gates for build, functional, security, and promotion stages, supported by a stable validation contract. The image pipeline concludes with a versioned, validated gallery artifact, which consumers can reference for controlled rollouts. Ultimately, treating image baking as a software delivery problem, with versioned outputs and independent validation, simplifies operations.