Anything inside Teams for people management you use and can recommend?
We currently have to use one tool for goals, another for feedback, a spreadsheet for review tracking, Teams for 1:1s, and then some shared doc for engagement notes. Leadership asked me if theres anything that does all of this inside Teams so they dont have to keep jumping around. We're a mid-size company (around 200 people) fully on Microsoft 365. Anyone found a good all-in-one solution that actually works inside Teams?How to use the new Chats & Channels experience in Teams
The new chats and channels experience in Microsoft Teams introduces several enhancements designed to improve collaboration and streamline communication. You can turn on this feature in preview for evaluation. These updates aim to make it easier for teams to collaborate, stay organized, and ensure that no important messages are missed. #MicrosoftTeams #Teams #NewFeatures #Microsoft365 #Productivity #MPVbuzzPlatform Improvements for Python AI Apps on Azure App Service
Overview Azure App Service (Linux) is a fully managed PaaS offering that supports a broad range of languages, including Python, Node.js, .NET, PHP, and Java. Developers can push source code or deploy a pre-built artifact; the platform handles the rest, including dependency installation, application containerization, and running the application at cloud scale. More customers are building intelligent applications using Azure AI Foundry and other AI services, and Python has become a language of choice for these workloads. The performance and reliability of the Python deployment pipeline directly shape the developer's experience on the platform, so we looked across the deployment path for opportunities to reduce latency and improve reliability. The first set of changes has reduced Python deployment latency on Azure App Service Linux by approximately 30%. This is the first step in a broader effort to make the platform better suited for AI application development, but the gains resulting from this effort will benefit all apps on the platform. Let's look at the details. Where Deployment Time Was Going Python web application deployments on Azure App Service Linux rely on Oryx, the platform's open-source build system, to produce runnable artifacts during remote builds. Platform telemetry showed that around 70% of Python app deployments use remote builds, and the majority of those resolve dependencies via requirements.txt using pip install. To understand where time was going, we profiled a stress workload: a 7.5 GB PyTorch application. Most production builds are smaller, but stress-testing a dependency-heavy application made the pipeline bottlenecks clear. When a Python app is deployed via remote build, the build container in Kudu (the App Service deployment service) runs Oryx to: Extract the uploaded source code. Create a Python virtual environment. Install dependencies via pip install; 4.35 min (~34% of build time). Copy files to a staging directory; 0.98 min (~8%). Compress via tar + gzip into an archive; 7.53 min (~58%). Write the archive to /home (Azure Storage SMB mount). The app container then extracts this archive to the local disk on every cold start. Why the Archive-Based Approach? The /home directory is backed by an Azure Storage SMB mount, where small-file I/O is comparatively expensive. Python dependencies are file-heavy: virtual environments commonly contain tens of thousands of files, and dependency-heavy ML applications can exceed 200,000 files. Writing those files individually over SMB would be prohibitively slow. Instead, the pipeline builds on the container's local filesystem, writes a single compressed archive over SMB, and the app container extracts it locally on startup for efficient module loading. Key insight: Compression was the single largest phase at 58% of build time, longer than installing the packages themselves. What We Changed Zstandard Compression (Replacing gzip) Standard gzip compression is single-threaded. In our benchmark, compression accounted for 58% of total build time, making it the dominant bottleneck. Because the archive is also decompressed during container startup, decompression time affects runtime startup latency as well. We evaluated three compression algorithms: gzip, LZ4, and Zstandard (zstd). The following results are averaged across multiple deployments of a 7.5 GB Python application with PyTorch and additional ML packages: Metric gzip LZ4 zstd Compression time 7.53 min 1.20 min 1.18 min Decompression time 2.80 min 1.18 min 1.07 min Archive size 4.0 GB 5.0 GB 4.8 GB Both zstd and LZ4 were more than 6× faster than gzip for compression and more than 2× faster for decompression. We selected zstd for the following reasons: Comparable speed to LZ4, with smaller archive sizes (4.8 GB vs. 5.0 GB). Mature ecosystem: zstd is based on RFC 8878 published in 2021 and ships with many common Linux distributions. Native tar support: tar –I zstd works out of the box; no extra packages required. Result: Compression time dropped from 7.53 min → 1.18 min (6.4× faster). Decompression improved from 2.80 min → 1.07 min (2.6× faster), directly reducing cold-start latency. Faster Package Installation with uv pip is implemented in Python and has historically optimized compatibility over maximum parallelism. In dependency-heavy workloads, package download, resolution, and installation can become a major part of deployment time. In our 7.5 GB PyTorch benchmark, package installation accounted for ~34% of total build time (4.35 min out of 12.86 min). We introduced uv, a Python package manager written in Rust, as the primary installer for compatible requirements.txt deployments. Its uv pip install interface works with standard pip workflows. Fallback strategy: Compatibility remains the priority. When uv cannot handle a deployment, the platform retries with pip, preserving the behavior customers already depend on. Cache behavior: Package caches remain local to the build container. When the same app is deployed again before the kudu (build) container is recycled, both pip and uv can reuse cached packages and avoid repeated downloads. Result: Package installation time dropped from 4.35 min → 1.50 min (3× faster). Reducing File Copy Overhead A file copy showed up in two places. First, before compression, the build process copied the entire build directory (application code plus Python packages) to a staging location. This existed historically as a safety measure; creating a clean snapshot before tar reads the file tree. But the cost was steep for the large number of files inherent in Python dependencies. The fix was straightforward: create the tar archive directly from the build directory, skipping the intermediate copy entirely. Second, for pre-built deployment scenarios, we replaced the legacy Kudu sync path with Linux-native rsync. That gave us a better optimized tool for large Linux file trees and reduced the overhead of moving files into the final deployment location. Because this path is used beyond Python, the improvement benefits pre-built apps across the broader App Service Linux ecosystem. Result: Eliminated the 0.98-minute staging copy (8% of build time), reduced temporary disk usage, and improved the remaining file sync path. Pre-Built Python Wheels Cache We added a complementary optimization: a read-only cache of pre-built wheels for commonly used Python packages, selected using platform telemetry. The cache is mounted into the Kudu build container at runtime for Python workloads, allowing the installer to use local wheel artifacts before downloading packages externally. When a matching wheel is available, the installer uses it directly, avoiding a network fetch for that package. Cache misses fall back to the upstream registry (e.g., PyPI) as usual. The cache is managed by the platform and kept up to date, so supported Python builds can use it without any app change. Combined Results Controlled Benchmark (PyTorch 7.5 GB, P1mv3 App Service Tier) The following benchmark was measured on the P1mv3 App Service tier. Values in the "After" column reflect the optimized pipeline with zstd compression, uv package installation, direct tar creation, and the pre-built wheels cache enabled together. Phase Before After Improvement Package installation 4.35 min 1.50 min ~3× faster File copy 0.98 min 0 min Eliminated Compression 7.53 min 1.18 min ~6× faster Total build time 12.86 min ~2.68 min ~79% reduction Production Fleet (All Python Linux Web Apps) Production telemetry across Python deployments shows the impact of these changes: deployment latency decreased by approximately 30% after the rollout. The controlled benchmark shows a larger improvement (~79%) because it exercises a dependency-heavy workload where package installation, file copy, and compression dominate total build time. Typical production apps are smaller and spend less time proportionally in those phases. Beyond Faster Builds: Reliability and Runtime Performance Faster builds only help when deployment requests reliably reach a worker that is ready to build. We updated the primary deployment clients Azure CLI, GitHub Actions, and Azure DevOps Pipelines to warm up Kudu before initiating deployments. Clients now issue a lightweight health-check request to the Kudu endpoint, helping ensure the deployment container is running and ready before the deployment begins. Clients also preserve affinity to the warmed-up worker using the ARR affinity cookie returned by the first request. This increases the chance that the deployment uses a worker with Kudu already running and local package caches already available from recent deployments. Together, these client-side changes reduced deployment failures from transient infrastructure issues and helped the pipeline optimizations reach the build phase reliably. Result: Deployment failures caused by cold-start errors (502, 503, 499) dropped by ~30%. We also improved the default runtime configuration for Python apps using the platform-provided Gunicorn startup path. Previously, the platform defaulted to a single worker, leaving most CPU cores idle. Now, it follows Gunicorn's recommended worker formula, fully utilizing available cores on multi-core SKUs and delivering higher request throughput out of the box. workers = (2 × NUM_CORES) + 1 Key Takeaways Measure before optimizing: Platform telemetry showed that remote builds and requirements.txt based installs were the dominant Python deployment paths, which helped us focus on changes that would benefit the most customers. Compression was the biggest bottleneck: In the dependency-heavy benchmark, archive compression took longer than package installation. Replacing gzip with zstd reduced both build time and cold-start extraction time. File count matters: Python virtual environments can contain tens of thousands of files, and AI workloads can contain many more. Reducing unnecessary file copies and using Linux-native file sync helped lower overhead. Compatibility needs a fallback path: Introducing uv improved the common path, while falling back to pip preserved compatibility for apps that depend on existing Python packaging behavior. Deployment reliability is part of performance: Faster builds only help if deployment requests consistently reach a ready worker. Warm-up and worker affinity made the optimized path more reliable for customers. Beyond deployment: Runtime defaults, such as Gunicorn worker configuration, also affect how production apps perform once deployment is complete. Together, these changes made Python deployments faster and more reliable while preserving compatibility through safe fallbacks. We will continue improving the platform to make Azure App Service faster, more reliable, and better suited for AI application development.
News to Know – Volume 3, Edition 5, May 2026
This month’s newsletter brings you the latest updates, insights and learnings to help you turn employee listening into action with Viva Glint & Pulse. As organizations continue to navigate AI-driven change, we’re focused on helping you measure what matters, understand impact, and sustain momentum across your employee experience strategy. Important Note: There is a planned maintenance window taking place in the Viva Glint platform on May 31, 2026, starting at 1:00am Pacific time (PDT) to make updates to the SFTP infrastructure used for file-based integrations. The maintenance window is expected to last approximately 3–4 hours, during which time customers may experience limited access to both Viva Glint surveys and the platform. For more detail on what is changing and to understand what steps your organization may need to take before and after May 31st please read this blog post and visit this recently updated Learn article. New on your Viva Glint platform This section highlights new capabilities and updates now available to help you strengthen security, reporting, and administrative control in Viva Glint. Benchmark Refresh: Country and Region benchmark suites. Country and Region benchmarks have been refreshed as part of the annual benchmark update cycle. These benchmarks are labeled “Country/Region 2025 (Calendar Year)” to reflect that they are based on data collected between January 1, 2025 and December 31, 2025. As part of this refresh, coverage has been updated—Costa Rica has been added, while Serbia has been removed due to insufficient data coverage—ensuring that all published benchmarks meet minimum data thresholds for reliability. We will be refreshing the Industry benchmark suite in the coming months. To access external benchmark comparisons in reporting, customers must opt in to benchmarking. Opting in increases the overall benchmark data pool, improves data coverage, and supports a broader set of benchmark suites. Customers who have not opted in won’t be able to view or include external benchmarks in their reports. Reporting Integrations: Additional controls for data flow from Insights to Glint. Now when you enable data flow from Insights to Glint, you will have the ability to exclude specific users and groups from having their metrics sent over. The control will be available in the Viva Glint section of Viva Feature Access Management in the M365 Admin Center. This is useful for tenants who operate in regions or parts of the organization where further approvals are needed to use workplace metrics data. You can exclude those users and groups from the feature until you get the approvals needed. More information can be found here. Coming soon to Viva Glint The following section offers an early look at capabilities coming to Glint shaping the future of continuous listening, analytics, and AI‑powered insight. Please note that public documentation (e.g., MS Learn articles) is not typically published until a feature is generally available. Copilot-supported commenting for Viva Glint survey takers | Private preview starting May. *Update: We previously shared that this would be generally available in May; instead, we’ll start with a private preview to allow additional development and testing ahead of broader release later this year. Soon, Viva Glint survey participants will be able to use an in-survey Copilot experience to polish their written feedback (please note: this capability is not available for respondents accessing surveys via attribute-based login or personalized links). Copilot can rephrase comments so employees can communicate more clearly and with greater confidence. By helping reduce distinctive writing patterns and making it easier to provide thoughtful input, the feature can increase comfort and perceived privacy—driving higher participation, richer responses, and more candid insights that organizations can act on. Custom data retention policy | Generally available starting June. Viva Glint admins will be able to configure a data retention policy for their Glint instance, defining how long Glint data is retained before it is deleted in accordance with organizational and compliance requirements. This feature enables admins to align Viva Glint data retention with company policies and compliance standards without relying on manual or backend-only processes. Custom confidentiality statement | Generally available starting June. Viva Glint admins will have the option to use Glint’s default confidentiality statement in their survey programs, or they can opt to turn off the default Glint confidentiality statement and define their own organization‑specific privacy messaging. This enables clearer, context‑appropriate communication to survey participants while maintaining Viva Glint’s core confidentiality protections and trust standards. The update helps organizations meet legal, compliance, and cultural requirements without compromising employee trust. “Select All” toggle for report filters | General availability coming soon. A new “Select All” option in the reporting filter panel will let users select or clear every attribute value in one click. This removes the pain of managing filters with long value lists, speeding up analysis and reducing manual effort. We aim to make this feature generally available in the next couple of months. Copilot Reporting: Dynamic Topics with Copilot | General availability coming soon. By leveraging Copilot, this functionality is designed to enhance the relevance and context of comment themes by extending beyond the current static set of topics and identifying customer-specific topics that can be tracked over time. These custom topics will remain confined to your platform and will not be accessible to Microsoft or other customers. This feature will also improve the accuracy of assignment to topics for both standard and dynamic categorization. We aim to make this feature generally available in the next couple of months. Seamless Entra authorization for MTO organizations | Private preview starting May. This new feature will simplify sign‑in for multi‑tenant organizations by introducing automatic tenant discovery. This new Entra‑based experience reduces reliance on MTO policies, lowers admin overhead, and aligns Viva Glint access with standard Microsoft 365 sign‑in—delivering a more scalable and seamless authentication experience. For scenarios where users need to explicitly access a different tenant (for example, guest or support access), domain selection remains available to ensure flexibility and control. We are aiming to make this generally available to our MTO customers starting in June. Continuous Employee Engagement with Workplace Metrics | Private preview starting May. Improve actionability for Work-Life Balance and Collaboration focus areas by integrating Viva Insights workplace metrics into Glint reporting. This feature will help Senior Leaders in your organization access supplementary data points, in conjunction with survey responses, to better understand their team's experience and conduct more data-driven discussions on what can be improved in these areas. Between survey cycles, leaders can also enable notifications to keep track of changes in their team's workplace patterns, allowing them to keep a better pulse on behavior change commitments. Private Preview is targeted in May 2026. Future capabilities will include the ability to map Viva Insights and Copilot metrics to survey items and bring in additional data sources from M365, such as meeting metadata and content. To express your interest, please complete the following: Private Preview: Continuous Employee Engagement with Workplace Metrics. If you are already part of the Employee Experience Customer Connection (EECC) program, request to join our Workplace Patterns & Continuous Listening EECC Teams subchannel through the main Glint EECC Teams channel so you can iterate on the future of continuous engagement with the product team in monthly calls. If you aren’t already part of the EECC, see the Connect with us section in this newsletter for more detail on how to join. Employee Feedback Agent | Private preview ongoing. Enhance your Employee Listen program with The Employee Feedback Agent a dynamic, AI-powered conversation, where employees can share what matters most through natural, chat-like interactions, whether prompted or always-on, enabling real-time feedback and deeper insights into the drivers behind their experiences. By combining Copilot intelligence and People Science principles, the agent streamlines feedback collection and reduces administrative overhead for HR and leaders. Unlike traditional Copilot tools that simply summarize information, the Employee Feedback Agent collects experiential data through probing questions and back and forth dialogue with employees. Future capabilities will expand impact with an actionable insights reporting experience, accelerating the “feedback-to-action” cycle. Raw Data Export API Egress | Private preview ongoing. Unlock seamless, automated access to raw survey data—no more manual downloads. Built on Microsoft Graph, these APIs make integrations easier and help admins move faster with greater efficiency. Express your interest here. See our public roadmap for more feature updates. Events and learning opportunities Stay up to date with upcoming events, recent documentation updates, and highlights from EECC customer sessions—designed to help you learn, connect, and get more value from Viva Glint & Pulse. Recent documentation enhancements: Have technical questions about Viva Glint? Microsoft Learn is your best source for clear, current guidance. We’ve expanded and refined our documentation to add detail on new capabilities, address frequent questions, and strengthen the topics customers rely on most. These updates improve clarity and consistency, making it easier to use Viva Glint with confidence. Below are a few of the most impactful recent updates now live on Microsoft Learn: Copilot access when using the “Log in as” experience added to FAQ Additional guidance around attribute configuration for Alert reports Important note added pertaining to Viva Insights data being sent to Viva Glint Clarification about Broader Team Insights configuration New SFTP IP exception details and current guidance for managing upcoming changes added EECC Customer Engagement Sessions: Upcoming sessions: May 28th, 8am PT/4pm ET – Help Shape What’s Next for Viva Glint 360 Assessments If you have opted in to EECC and are interested in participating in this session, please mark your calendar. Invites with registration link will soon be sent to all EECC members and an EECC Teams post with registration link will be posted soon! Target Audience: Viva Glint 360 Admins We’re inviting all Viva Glint 360 Assessment admins for an interactive listening session focused on the real-world experience of running 360 assessments in Viva Glint and we’d love your voice at the table. This is an opportunity for you to directly influence what comes next for Viva Glint 360s. While 360s exist in Glint today, they haven’t evolved significantly—and your insights will help determine where we invest going forward. What we’ll focus on: Where the 360 process creates friction for admins, managers, and participants Moments where workflows slow down, break, or require manual workarounds Small, high-impact improvements that could meaningfully improve the experience Expect a candid, discussion-driven session with peers who are actively running 360s and ready to share what’s working—and what’s not. Previous sessions: April 23rd - Notifications and Nudges Admin Experience in Viva Glint In this recent EECC session, we discussed how organizations are using survey notifications and Nudges in Microsoft Glint today and explored opportunities to improve the overall experience. The forum brought Viva Glint admins together to validate early ideas, share practical approaches, and provide feedback to help shape future enhancements to notification capabilities. The session covered current notification workflows used in survey programs, insights gathered from existing customer feedback channels, and early concepts for enhancements in the notifications and Nudges space. Participants highlighted gaps in the current admin and program-design experience and offered direct input on where the platform could better meet day-to-day needs. Key takeaways from the discussion included: Consensus of pain points across customer orgs and the need for foundational improvements to the notification configuration process Current Viva Glint prioritization of notification enhancements aligns well with customer expectations/enhancement desires Tangential enhancement opportunities exist that would support more seamless user experience around notifications (e.g., in-platform usage metrics, testing, etc.) If you are not yet a member of the Employee Experience Customer Connection (EECC) but would like to participate in upcoming sessions, as well as gain access to numerous other engaging and valuable Glint and Pulse customer activities, please see the sign-up information below. New Thought Leadership Explore the latest research and perspectives from our People Science team on leadership, AI, and the evolving employee experience. Research Drop: The Human Conditions Behind AI Value at Work. Not all employee experience factors predict AI value equally, and across three People Science surveys, they haven't held steady either. This Research Drop maps which EX conditions are stable, which are rising, and which fluctuate with context, pointing to what organizations need to build, not just deploy, to sustain real AI value. Read it here. Connect with us Stay engaged with the Viva Glint & Pulse community through the Employee Experience Customer Connection (EECC) program. The Employee Experience Customer Connection (EECC) program offers our customers an opportunity to be part of a feedback community as employee experiences continue to evolve with Viva and Microsoft 365 Copilot. What the program provides: Product team engagement for Employee Experiences powered by Viva and M365Copilot Forums for you to influence product direction & unlock value for your organization Early insight into product roadmap Private preview engagement opportunities Connection with other enterprise customers If you’re interested in joining, please fill out this form so we can guide you through the enrollment process and help you get started. We look forward to partnering with you to build better products—together.From Prompt to Production: Open in VS Code for Terraform in Azure Copilot
We’re excited to introduce a new step in the Terraform on Azure experience: Open in VS Code, now available directly from Azure Copilot in the Azure Portal. This capability helps you move seamlessly from AI‑generated Terraform code to real Azure deployments - within a connected, guided workflow designed for enterprise scenarios. Why This Matters Infrastructure as Code with Terraform is powerful, but moving from generated configuration to a deployed environment typically involves multiple tools and handoffs. Teams need to understand Terraform state, work with remote backends, and integrate their code into version‑controlled CI/CD pipelines - often backed by Terraform Cloud or Azure‑native backends in enterprise environments. Open in VS Code brings these steps together. It bridges the gap between AI‑assisted authoring in the Azure Portal and the real‑world workflows required to validate, manage state, and deploy infrastructure with confidence. Continue Your Workflow in VS Code With Azure Copilot, you can describe your infrastructure in natural language and generate Terraform configurations in seconds. For example: “Create an Azure Container App using Terraform with a managed environment, Log Analytics enabled, and a system‑assigned managed identity to securely pull images from Azure Container Registry.” Copilot generates the Terraform configuration for you. From there, you can select Open full view to enter a full‑screen Terraform editor, and then choose Open in VS Code to launch the configuration in an Azure‑hosted VS Code environment. There’s no need to download files or set up a local development environment. VS Code for the web opens with Azure authentication already configured, along with commonly used extensions, so you can immediately focus on refining, validating, and preparing your infrastructure for deployment. Built‑in Guidance for Real Deployments Beyond editing, the VS Code experience includes built‑in, step‑by‑step guidance to help you deploy your Terraform configuration into your own Azure environment - whether you’re experimenting or preparing for production. Because Terraform relies on state management, the workflow starts by helping you choose and configure a backend. Backend Options Option 1: Azure Storage Account as a remote backend A natural fit for Azure‑native and enterprise environments. The experience guides you through creating or selecting a storage account and configuring Terraform to store state securely in Azure. Option 2: HCP Terraform (Terraform Cloud) as a remote backend Ideal for teams already using Terraform Cloud. The guided flow helps you authenticate, connect to an existing organization and workspace, and generate the required backend configuration directly into your Terraform files. Option 3: Temporary workspace for quick validation Designed for learning and experimentation. You can run terraform plan and terraform apply directly in the Azure workspace with temporary state, without committing to a long‑term backend - ideal for quick validation, but not intended for production use. Each option includes an end‑to‑end walkthrough, so you can complete backend setup and run Terraform commands without leaving the VS Code environment or searching through external documentation. Connecting Code, State, and Deployment This experience connects three essential parts of the Terraform workflow: AI‑assisted code generation in Azure Portal Copilot Interactive editing and guided execution in VS Code for the web Flexible backend options for managing Terraform state Together, these pieces make it easier to move from idea to infrastructure in a structured, supported way—whether you’re new to Terraform or managing production workloads with established CI/CD pipelines. Available Now - and What’s Next The Open in VS Code experience for Terraform is now public preview in Azure Portal Copilot. We’re continuing to invest in this workflow, including clearer deployment guidance, future integration with GitHub Actions and other CI/CD pipelines, and deeper enhancements to the full‑screen Terraform editor experience. If you haven’t tried it yet, generate a Terraform configuration with Azure Copilot and open it in VS Code to go from prompt to production end to end in one connected workflow.Running Foundry Agent Service on Azure Container Apps
Microsoft’s Customer Zero blog series gives an insider view of how Microsoft builds and operates Microsoft using our trusted, enterprise-grade agentic platform. Learn best practices from our engineering teams with real-world lessons, architectural patterns, and operational strategies for pressure-tested solutions in building, operating, and scaling AI apps and agent fleets across the organization. Challenge: Scaling agents to production changes the requirements As teams move from experimenting with AI agents to running them in production, the questions they ask begin to change. Early prototypes often focus on whether an agent can reason to generate useful output. But once agents are placed into real systems where they continuously need to serve users and respond to events, new concerns quickly take center stage: reliability, scale, observability, security, and long‑running operations. A common misconception at this stage is to think of an agent as a simple chatbot wrapped around an API. In practice, an AI agent is something very different. It is a service that listens, thinks, and acts, ingesting unstructured inputs, reasoning over context, and producing outputs that may span multiple phases. Treating agents as services means teams often need more than they initially expect: dependable compute, strong security, and real-time visibility to run agents safely and effectively at scale. When we kick off an agent loop, we provide input that informs the context it recalls for the task, the data it connects to, the tools it calls, and the reasoning steps it outlines for itself to generate an output. Agent needs are different from traditional services in hosting, scaling, identity, security, and observability; it’s a product with a probabilistic nature that requires secure, auditable access to many resources at the same lightspeed performance that users expect from any software. This isn’t the first time that the software industry needed to evolve its thinking around infrastructure. When modern application architectures began shifting from monolithic apps toward microservices, existing infrastructure wasn’t built with that model in mind. As systems were reconstructed into independent services, teams quickly discovered they needed new runtime architecture that properly accommodated microservice needs. The modern app era brought new levels of performance, reliability, and scalability of apps, but it also warranted that we rebuild app infrastructure with container orchestration and new operational patterns in mind. AI agents represent a similar inflection. Infrastructure designed for request‑response applications or stateless workloads wasn’t built with long‑running, tool‑calling, AI‑driven workflows in mind. As the builders of Foundry Agent Service, we were very aware that traditional architectures wouldn’t hold up to the bursty agentic workflows that needed to aggregate data across sources, connect to several simultaneous tools, and reason through execution plans for the output that we needed. Rather than building new infrastructure from scratch, the choice for building on Azure Container Apps was clear. With over a million Apps hosted on Azure Container Apps, it was the tried-and-true solution we needed to keep our team focused on building agent intelligence and behavior instead of the plumbing underneath. Solution: Building Foundry Agent Service on a resilient agent runtime foundation Foundry Agent Service is Microsoft’s fully managed platform for building, deploying, and scaling AI agents as production services. Builders start by choosing their preferred framework or immediately building an agent inside Foundry, while Foundry Agent Service handles the operational complexity required to run agents at scale. Let’s use the example of a sales agent in Foundry Agent Service. You might have a salesperson who prompts a sales agent with “Help me prepare for my upcoming meeting with customer Contoso.” The agent is going to kick off several processes across data and tools to generate the best answer: Work IQ to understand Teams conversations with Contoso, Fabric IQ for current product usage and forecast trends, Foundry IQ to do an AI search over internal sales materials, and even GitHub Copilot SDK to generate and execute code that can draft PowerPoint and Word artifacts for the meeting. And this is just one agent; more than 20,000 customers rely on Foundry Agent Service. At the core of Foundry Agent Service is a dedicated agent runtime through Azure Container Apps that explicitly meets our demands for production agents. Agent runtime through flexible cloud infrastructure allows builders to focus on making powerful agent experiences without worrying about under-the-hood compute and configurations. This runtime is built around five foundational pillars: Fast startup and resume. Agents are event‑driven and often bursty. Responsiveness depends on the ability to start or resume execution quickly when events arrive. Built‑in agent tool execution. Agents must securely execute tool calls like APIs, workflows, and services as part of their reasoning process, without fragile glue code or ad‑hoc orchestration. State persistence and restore. Many agent workflows are long‑running and multi‑phase. The runtime must allow agents to reason, pause, and resume with safely preserved state. Strong isolation per agent task. As agents execute code and tools dynamically, isolation is critical to prevent data leakage and contain blast radius. Secure by default. Identity, access, and execution controls are enforced at the runtime layer rather than bolted on after the fact. Together, these pillars define what it means to run AI agents as first‑class production services. Impact: How Azure Container Apps powers agent runtime Building and operating agent infrastructure from scratch introduces unnecessary complexity and risk. Azure Container Apps has been pressure‑tested at Microsoft scale, proving to be a powerful, serverless foundation for running AI workloads and aligns naturally with the needs of agent runtime. It provides serverless, event‑driven scaling with fast startup and scale‑to‑zero, which is critical for agents with unpredictable execution patterns. Execution is secure by default, with built‑in identity, isolation, and security boundaries enforced at the platform layer. Azure Container Apps natively supports running MCP servers and executing full agent workflows, while Container Apps jobs enable on‑demand tool execution for discrete units of work without custom orchestration. For scenarios involving AI‑generated or untrusted code, dynamic sessions allow execution in isolated sandboxes, keeping blast radius contained. Azure Container Apps also supports running model inference directly within the container boundary, helping preserve data residency and reduce unnecessary data movement. Learnings for your agent runtime foundation Make infrastructure flexible with serverless architecture. AI systems move too fast to create infrastructure from scratch. With bursty, unpredictable agent workloads, sub‑second startup times and serverless scaling are critical. Simplify heavy lifting. Developers should focus on agent behavior, tool invocation, and workflow design instead of infrastructure plumbing. Using trusted cloud infrastructure, pain points like making sure agents run in isolated sandboxes, properly applying security policy to agent IDs, and ensuring secure connections to virtual networks are already solved. When you simplify the operational overhead, you make it easier for developers to focus on meaningful innovation. Invest in visibility and monitoring. Strong observability enables faster iteration, safer evolution, and continuous self‑correction for both humans and agents as systems adapt over time. Want to learn more? Learn about building and hosting agents with Foundry Agent Service Discover agent runtime through Azure Container Apps Read about best practices for managing agents
Planner task comments no longer send email notifications – critical regression
This change removed a previously existing core functionality without providing an adequate replacement. With the new Planner experience, task comments no longer trigger automatic email notifications to assigned users. This breaks a critical communication mechanism that many teams relied on for reliable task coordination. As a result, assigned users are no longer consistently informed about updates, introducing a high risk of missed information and operational issues in day-to-day work. There is currently no supported or enforceable alternative to ensure users are notified. Previous behavior: Task comments triggered automatic email notifications Assigned users were reliably informed Communication was traceable and consistent Current behavior: No automatic email notifications No configuration to restore this @mentions required (manual, error-prone, not enforceable) Microsoft Support has confirmed that this is by design and cannot be reverted. From an enterprise perspective, this is not just a design change, but a regression of critical functionality without an equivalent replacement. Request: Please restore automatic email notifications for task discussions or provide a reliable, enforceable alternative for notifying assigned users. Question to the community: How are you handling this change in real-world scenarios? Switching tools? Enforcing @mentions? Moving communication out of Planner? Would appreciate hearing how others are dealing with this.Better together with Azure WAF + Microsoft Defender for Storage + Defender for Azure SQL Databases
Authored by: Fernanda_Vela , saikishor, Yura_Lee Reviewed by: YuriDiogenes, Mohit_Kumar, Amir_Dahan, eitanbremler , Kitt_Weatherman Introduction Often, customers ask why additional workload protection is needed when a web application firewall is already in place. Azure Web Application Firewall (WAF) serves as a critical control at the application edge, inspecting inbound HTTP/S traffic and blocking common web-based exploits before they reach backend services. However, modern attack paths are no longer limited to the web entry point. Attackers increasingly target components that bypass HTTP/S inspection altogether such as direct access to storage and SQL through SDKs, native integration tools, private endpoints, or compromised identities and third-party integrations. This is where Microsoft Defender for Cloud complements WAF. While WAF focuses on securing the application boundary, Defender for Cloud extends protection into the resource layer by providing Cloud-Native Application Protection Platform (CNAPP) capabilities, including security posture management and workload protection. Using resource-native signals, it helps identify misconfigurations and detect suspicious control-plane and data-plane activity that would otherwise remain invisible to perimeter controls. The Azure Networking Security blog post “Zero Trust with Azure Firewall, Azure DDoS Protection, and Azure WAF: A practical approach” highlights WAF’s role in inspecting inbound HTTP/S traffic, detecting malicious request patterns (such as OWASP Top 10 vulnerabilities), and reducing direct exposure of backend endpoints by enforcing a controlled application entry point. Building on that foundation, this blog focuses on a “better together” approach that combines WAF with Microsoft Defender for Cloud protecting storage and database. Through practical scenarios and posture insights, we will underline how these controls together: Reduces attack surface at the application entry point Continuously improves security posture through configuration and exposure analysis Detects and responds to threats targeting storage accounts and SQL databases beyond the web perimeter By the end of this post, you will understand how Defender for Cloud’s Storage and SQL protections extend the visibility provided by WAF, enabling protection not only at the edge, but also across the underlying data services. Together, these controls form a cohesive model that addresses both external attack vectors and internal or indirect access paths. Note: This is not a deep configuration guide for rule tuning, nor a replacement for official product documentation. It is intended to help architects and security teams align responsibilities and understand how these services reinforce each other. Architecture: The architecture below shows the traffic flow and where each service fits in the lab used in this blog to simulate the attacks. Azure Application Gateway with WAF is the internet-facing entry point, inspecting inbound HTTP/S traffic before it reaches the backend. Behind it, Azure Firewall provides both network- and application-layer inspection for inbound and outbound flows. In the backend subnet, multiple VMs host the workload. For our demonstration, we focus on a single host running: OWASP Juice Shop (port 3000), An upload API that writes to Azure Storage (port 8080) An API that connects to Azure SQL Database (port 5000). This setup allows us to simulate realistic attack paths originating both from the internet and from within the network. Figure 1: Architecture that shows resources with Application Gateway with WAF, Azure Firewall Premium and inbound traffic Note: The patterns in this blog apply to both Azure WAF platforms: Application Gateway WAF and Azure Front Door WAF. The lab uses Application Gateway WAF for the demonstration. Now, let’s head to the next section where we dive deep into these services to understand their capabilities with some attacks, alerts and insights. Azure Web Application Firewall at the Edge As we may have understood by now, Azure WAF is the first layer of protection, inspecting external web traffic for malicious patterns. Each incoming request is evaluated against its rulesets to either allow, block or log this traffic by using its managed and custom rulesets. Now, what are these rulesets? Azure WAF uses managed rule sets like the Default Rule Set (DRS) (version 2.2 as of this writing), which incorporate OWASP Top 10 protections and Microsoft threat intelligence to block common attacks (SQL injection, XSS, remote file inclusion, etc.) in real time. Additional managed sets include a Bot Protection rule set (to guard against malicious bots scraping content) and HTTP DDoS rule set (to detect Layer 7 DDoS patterns). Beyond the built-ins, you can define custom WAF rules for application-specific needs—blocking or allowing traffic based on attributes like geolocation, IP ranges, or specific URL paths. Now let’s talk about an example scenario. In our lab, Azure WAF is protecting multiple backend services on different paths and ports. When an external attacker tries to exploit the Juice Shop app with a crafted XSSattack, Azure WAF immediately detects the malicious pattern and blocks the request at the gateway as seen below. Figure 2: An XSS attack on the juiceshop website, immediately results in a 403 Forbidden as WAF catches this attack in the application layer. However, WAF’s inspection is inherently limited to traffic it can see, primarily, the HTTP/S flows it fronts. Let’s say our attacker changes tactics: instead of trying to force malicious code through the web interface, they obtain a stolen storage key or credentials through phishing and attempt to access the Azure Storage account directly via APIs. This request never goes through WAF, so WAF cannot assess or block it. In such a case, Microsoft Defender for Storage’s threat detection monitors for such suspicious activity, for example by raising an alert about the unusual direct access or flagging a malware file uploaded to a blob container. Likewise, if our attacker exploited a weakness in application code to run malicious SQL commands on the database (whether through potentially harmful application or a suspicious service account), Defender for SQL monitors for and alerts anomalous query patterns or suspicious logins. This illustrates why WAF and Defender for Cloud are complementary: WAF stops web attacks at the door, while Defender for Cloud watches for threats that get inside or come through alternate doors. Figure 3: Single-host lab architecture with Azure Application Gateway (WAF) and resource‑level protection Figure 3 illustrates the key distinction: WAF inspects and protects the application entry point, while Defender for Cloud provides visibility into the resources themselves. Together, they cover both the path into the application and the behavior within the environment—forming a complete protection model across layers. Because not all access to storage and databases may flow through the application gateway, you also need resource-level posture and threat detection to see and stop activity that never appears in WAF logs. Cloud Security Posture Management with Defender for Cloud With the edge covered, the next challenge is reducing risk that originates from misconfiguration and resource exposure. Most successful attacks originate from exposed services and misconfigurations rather than direct application-layer exploits. Microsoft Defender for Cloud’s storage and database protection provide security posture insights that help identify and prioritize these security gaps at the resource level. Defender for Cloud has visibility insights that capture the resources’ misconfigurations on the control and data plane via the Recommendations view in the Azure portal, as shown in the example below: Figure 4: Juice Shop’s storage account and SQL server recommendations Figure 4 is a list of recommendations organized by risk level for this particular environment. The security team should harden the “defendertestsai” storage asset by preventing shared access keys, and the “juiceshop” SQL database by provisioning an Entra administrator. Each recommendation will also provide guidance to remediate these findings. The “Data & AI Dashboard” in Defender for Cloud, with Defender CSPM, will also provide security posture insight into storage, database and AI resources by surfacing their risks, alerts and sensitive data discovery all in one dashboard. Figure 5: Juice Shop’s Sensitive data discovery and Data threat detection dashboard in Defender for Cloud’s “Data&AI section”. Under Data closer look, in Figure 5, you can see in this example, starting from the left, sensitive information found in scanned resources, level alerts for databases and storage resources based on severity, templatized queries from the Cloud Security Explorer, and a graph displaying all internet exposed data resources below. These powerful insights on data resources all come from Defender for Cloud, designed to help customers harden their environment by priority through visibility across their entire data ecosystem based on risk level. Figure 6: Juice Shop’s attack path “Internet exposed Azure VM with high severity vulnerabilities allows lateral movement to Critical Storage used by Azure AI Foundry”. Attack paths are potential avenues in which an attacker can infiltrate and compromise data. In Figure 6 above, we see insight into not only the storage account itself, but the context around it: an internet exposed storage account is connected to other assets like a virtual machine and a managed identity that has permissions to manipulate data. These Defender for Cloud security posture insights complement WAF and complete the defense-in-depth security approach: harden the data services so that even if an attacker reaches them the blast radius is smaller, and the likelihood of compromise is reduced. Defender for Cloud’s advanced threat protection Even in well-secured environments, attackers often interact directly with storage accounts or databases through identities, APIs, or trusted internal paths. Reducing exposure is critical but not sufficient. Detection is required once an attacker begins interacting with data Defender for Cloud’s advanced threat protection for Storage and SQL surfaces resource-level security alerts such as suspicious access patterns, anomalous queries, and malware detections—often with richer context than perimeter telemetry alone. Let’s use a malware alert for a storage account in the Defender portal as an example: Figure 7: Juice Shop’s storage account security alert “Malicious blob uploaded to storage account”. Malware scanning is a common requirement for teams that process user uploads or must meet security benchmarks. In this lab, Juice Shop allows users to upload files (for example, feedback attachments), and the upload API writes those files to Azure Blob Storage. Azure WAF inspects the HTTP request that delivers the upload headers, parameters, payload patterns and blocks web-layer attacks like XSS or SQLi. Scanning blob contents after they land is a different job, performed at the resource layer by Defender for Storage. With Defender for Storage malware scanning enabled, each uploaded blob is scanned; if the verdict is malware, Defender for Cloud raises an alert such as “Malicious blob uploaded to storage account” as shown in figure 7. Then, with Defender for Storage’s automated malware remediation, the malicious blog is set to soft-delete for quarantine and further analysis. SQL databases are high-value targets for data access, privilege escalation, and exploitation of vulnerable applications. Database protection in Defender for Cloud has the visibility to provide customers with control plane and data plane level insight to alert on suspicious activity such as anomalous logons, unusual client applications, and injection-like query patterns. For example, here’s a potential SQL injection alert for a database in the Defender portal: Figure 8: Juice Shop’s database security alert on a potential SQL injection. These alerts typically include investigation context such as the client application, client principal name, and the statement or pattern in question, along with severity to help you prioritize, as shown in Figure 8. From there, analysts can use recommended response actions (for example, to contain risky access paths or harden the database) to reduce the chance of repeat activity. In practice, Defender for Cloud threat detection gives SOC teams prioritized, resource-specific alerts with the context needed to investigate quickly and take action at the storage and database layers. Conclusion Azure Application Gateway with WAF is a necessary control to reduce application-layer risk at the edge. But defense in depth requires the assumption that some threats will reach or target data services directly. By layering Microsoft Defender for Storage and Microsoft Defender for SQL on top of Azure WAF, you add continuous posture insights to reduce preventable exposure, plus threat protection that detects suspicious activity at the resource layer. Operated together, these services provide stronger prevention, better detection coverage, and clearer response paths than single control alone.
Viva Engage for recognition feels limited, what are you all using?
We rolled out Viva Engage hoping the praise feature would help build a recognition culture but honestly its kinda buried and most employees forget its there. Our managers want something where giving recognition is part of the daily flow, like right inside a Teams chat or after a meeting. Are you running into difficulties with praise? Any best practices you can recommend so we can use it better? Or are you using something else?
