Azure Feeds

Jev Gives You Probabilities, Not Decisions

Fri, 09 Oct 2026 20:58:21 +0000

In my previous post , I showed how to use Jev in cloud engineering scenarios: filtering NSG rules, checking Bicep what-if output, and linting Azure Policy. I didn't explain how it works. This post covers the concepts and the mental model behind Jev. The examples still use PowerShell and Azure, but the ideas apply to any language and any scenario. I use Doug Finke's Jev PowerShell module , but you can use any language. Note: This post can be used with other decision-scoring models, but only Jev have been used here The principle TypeSafe, the company behind Jev, was inspired by Thinking, Fast and Slow, the bestseller everyone pretends to have read, by psychologist Daniel Kahneman. Kahneman describes two systems of thought. System 1 is fast and instinctive, like answering 2 + 2. System 2 is slow, effortful and logical, like counting how many times the letter a appears on a page. Jev is built on the System 1 idea. It's a new class of AI model: it doesn't generate text, it makes fast, structured decisions. An LLM takes text and returns text that you then have to parse. Jev takes text and returns a typed decision with probabilities and a confidence score, which you can use directly as a signal in a script, a program or a workflow. The cost model is different too. You only pay for input: $42 per billion input tokens, or $0.042 per million. Output is free, because it's always small. TypeSafe also claims response times between 70 and 500 ms (you need to add the network round trip). It seems coherent during my testing. Any Jev call use two inputs, the state or the context to evaluate and questions about the state. State: the context The state is the context you want to evaluate using Jev. It can be a message, a log, or application output. Jev supports three formats: string, JSON object, or array. `String: The customer is blocked by a connection issue to the database. JSON Object json { "securityRules": [ { "name": "allow-https", "properties": { "description": "Public HTTPS for the web site. Owner: web team", "protocol": "Tcp", "sourcePortRange": "*", "destinationPortRange": "443", "sourceAddressPrefix": "Internet", "destinationAddressPrefix": "*", "access": "Allow", "priority": 100, "direction": "Inbound", "sourcePortRanges": [], "destinationPortRanges": [], "sourceAddressPrefixes": [], "destinationAddressPrefixes": [] } } } Array: json ["Inbound", "Allow", "HTTPS"] TypeSafe recommand to use a JSON object, if possible and the string for simple task. The state contains the data, never the question. Clean it up when you can: remove empty fields, IDs and timestamps that don't matter for the decision. You save tokens and the model gets a clearer signal. The context window is limited to 32k tokens, and non-English texts gives less accurate results. Questions: the three primitives A Jev request evaluates the state against one or more questions. Each question is evaluated independently. There are 3 types of question: Score, Noul and Choice. Score A Score question rates the state against an ordered list of 2 to 10 descriptive levels, from lowest to highest. These levels are the criteria powershell $question = New-JevQuestion -Name risk -Type Score -Instructions 'How risky is it to deploy the changes in whatif ?' -Criteria @( 'No risk: cosmetic or read-only property changes' 'Low: new isolated resources' 'Medium: changes to shared network resources (VNets, peerings, route tables)' 'High: an outage or a security incident is likely' ) ` To get the result: `powershell $result = Invoke-Jev -State $summary -Question $question $result.answers.risk | convertTo-Json -Compress -Depth 10 ` The risk object look like `json { "type":"score", "score":2.49, "confidence":0.5, "legend":{ "0":"No risk: cosmetic or read-only property changes", "1":"Low: new isolated resources", "2":"Medium: changes to shared network resources (VNets, peerings, route tables)", "3":"High: an outage or a security incident is likely" }, "probabilities":{ "0":0.0, "1":0.01, "2":0.5, "3":0.49 } } ` The type, is the type of the question. The score is the probability-weighted mean of the level, here 2.49, between Medium and High. Legend, each level and their number. Probability, Probability for each level, the sum of each probability is equal to 1. Confidence, a number between 0 and 1 that shows how the probabilities are concentrated. In the example the probability for High and Medium are similar, and the confidence is 0.5. It's a coin flip between Medium (2) and High (3), the model can not judge, an humain should take a look. It is not "medium-high" risk. Noul A Noul question asks a yes/no question and returns the probability that the answer is yes. The criteria are optional, but if you set them, you must describe both true and false. ` powershell $feedback = [pscustomobject] @{ message = 'The customer is blocked by a connection issue to the database.' } define the criteria for the question $question = New-JevQuestion -Name noulquestion -Type Noul -Instructions 'Does the report give steps that would reproduce a defect?' -Criteria @{ true = 'The report describes a defect and gives concrete steps to reproduce it.' false = 'The report does not give concrete steps to reproduce a defect.' } invoke the question with the current state $result = Invoke-Jev -State $feedback -Question $question $result.answers.noulquestion ` The result: `json { "type":"noul noul":0.05 } ` Type of question; noul The noul property, the probability that the answer is true The noul property will give you the probability that the answer to the question is true. The probability of false is simply 1 − noul. Choice A Choice question selects one option from a set of 2 to 255. The criteria are a hashtable: each key is an option name and each value describes it. The instruction is the question for the model. And the criteria is an array of map. Add an unclear option to give the model a way out. Without one, it has to pick a team even when none fits. ` powershell $criteria = @{ support = 'The issue needs technical support.' sales = 'The issue concerns sales.' unclear = 'It is unclear which team should handle the issue.' } create the question based on the criteria $question = New-JevQuestion -Name TeamRouting -Type Choice -Instructions 'Which team should handle this?' -Criteria $criteria invoke the question with the current state $result = Invoke-Jev -State $feedback -Question $question check the result of the question $result.answers.TeamRouting ` The result: `json { "type":"choice", "choice":"support", "confidence":1.0, "probabilities":{ "support":1.0, "unclear":0.0, "sales":0.0 } } ` The type, is the type of the question Choice gives you the slected option. Confidence gives you a number between 0 and 1 on how probability is spread on the different options. A 1.0 means all the probability is on one option; lower values mean it's spread across several. Probabilities for the different option, the sum is always equal to 1. Probability, confidence and calibration Jev doesn't really give you decisions. It gives you probabilities, it is your role to turn them into decisions. For each question type you have probabilities, and you have confidence. Probabilities tell how likely the model thinks each option or level is. The distribution and the concentration between the possible answers is also important. This is how confidence is calculated. If the probabilities are concentrated on one option. For example a=0.9, b=0.06 and c=0.04. All the probability are on the option a, the model is confident. If they're spread across several options, a=0.4, b=0.33 and c=0.27. There is no clear winner, the model is uncertain. The noul question type doesn’t return a confidence, just the probability that of the true answer. But you can calculate it via this formula: `Confidence = | 2p – 1| Where p is the probability of the yes answer If p = 0.05 the confidence will be 0.9. Meaning the response is false with a large confidence If p = 0.95 the confidence will be 0.9, the confidence for the true is large. If p = 0.4 the confidence will be 0.2, the can choose an option and an humain should be involced. The answer to the question gives you “The What”, the confidence tells you how to act with it. If the confidence is higher or equal to 0.9 you should automated it, between 0.9 and 0.5 it needs a confirmation and bellow 0.5 it new a human investigation. This is the recommendations of TypeSafe. But you should build your own thresholds with your data. You need to take a set of data and create 30 to 60 different states where you know the correct answer and run tests. The average confidence of correct answers doesn't give you a threshold. Instead, sort results by confidence and find the lowest confidence above which accuracy meets your target (85% for example). That's your automation threshold. Writing good questions There is another way, to get the most of Jev is to know how to make good question. Question are the equivalent of a prompt in the LLM world. There are several patterns: Question should be atomic. Only one concern per question. For example, "Is the rule risk and undocumented" should be two questions: "is the rule risky" and "is the rule undocumented". Do not use Jev to get an answer a script can easly have. If it is deterministic, keep it in the code. Is port 22 open to the Internet?" is a script check. "Does this rule's description identify an owner?" is a Jev question. Criteria is the real prompt, the state is the data, Avoid vague and ambiguous criteria. Take a look at these options: "High: dangerous" versus "High: an outage or a security incident" is likely too ambigous. For Choice, options must not overlap (Ex "Tech Support" and "IT Support"). Batch question in one call, Jev can do parallel checks Example: ` powershell $questions = @( New-JevYesNoQuestion -Name security -Question 'Do the changes in whatif weaken the security of the environment?' -TrueCriteria 'Password login enabled on a VM, no NSG on a NIC or subnet, a security setting removed or relaxed' ` -FalseCriteria 'Security settings are unchanged or stronger' New-JevYesNoQuestion -Name public_ip ` -Question 'Do the changes in `whatif` expose a resource to the internet with a public IP?' ` -TrueCriteria 'A public IP address is created or attached to a NIC, a VM or a load balancer' ` -FalseCriteria 'No public IP is created or attached' New-JevQuestion -Name risk -Type Score ` -Instructions 'How risky is it to deploy the changes in `whatif`?' ` -Criteria @( 'No risk: cosmetic or read-only property changes' 'Low: new isolated resources' 'Medium: changes to shared network resources (VNets, peerings, route tables)' 'High: an outage or a security incident is likely' ) ) $state = @{ whatif = $summary -join "`n" } $answers = (Invoke-Jev -State $state -Question $questions -Mock:$Mock -Raw).answers ## conclusion Despite its name, what a decision model really gives you is probabilities: a signal that tells you when to automate and when to ask for review. Remember four things. The state is data, never the question. Each question covers one concern. The criteria are the real prompt. Measure your own thresholds, especially if your data isn't in English or state is very specific. Keep the limits in mind too. Jev returns numbers without reasoning, so you can't audit why it decided.

Retirement: Azure Key Vault Secrets Provider Extension for Azure Arc enabled Kubernetes clusters

Fri, 09 Oct 2026 20:27:17 +0000

The Azure Key Vault Secrets Provider Extension for Azure Arc-enabled Kubernetes will be retired on October 9, 2027.Customers currently using the extension should plan to migrate to the Azure Key Vault Secret Store Extension before the retirement date. The

Multi-NIC Support on AKS powered by DRANET – Now in Public Preview

Fri, 09 Oct 2026 18:24:27 +0000

Kubernetes was designed around a simple networking model, every pod gets one network interface, and every pod on a node shares the same flat network. For most stateless microservices, this works well as it keeps the model simple and the platform portable. But a large class of workloads don't fit that shape. Some need network separation, with management, control, and data traffic on separate and isolated networks rather than multiplexed over one interface. Other workloads need predictable performance, a dedicated path for high-throughput or latency-sensitive traffic. Until now, meeting these requirements on Kubernetes meant adding and manually integrating multiple components, or keeping the workload on VMs. Today we're announcing the public preview of multi-NIC support for pods on AKS, powered by the AKS managed DRANET driver. You can now provision worker nodes with multiple network interfaces connected to different subnets, and attach a dedicated interface directly to a pod using standard upstream Kubernetes APIs, with no Multus, no custom CNI extensions, and no manual interface wiring. Two ways to use multi-NIC on AKS Use case 1: A dedicated NIC attached directly to a pod “As a networking engineer, I want to attach a dedicated network interface directly to a Kubernetes pod so the workload can connect to different networks and route traffic natively, without relying on host-level DPDK/VPP forwarding, custom routing rules, or gateway-based NAT.” “I also want the secondary interface on my pod to send and receive traffic on a specific, known public IP address, so that downstream partners can allow-list my traffic by IP and no NAT hop adds latency to time-sensitive streams." This is the pattern where the workload itself expects to see multiple interfaces. The pod asks for a network device the same way it would ask for any other resource, and the interface shows up inside the container alongside the standard CNI interface. No host-level forwarding layer, no NAT gateway in the middle. What you get The DRANET driver is deployed automatically. Once a node pool is configured with secondary interfaces, AKS installs and manages the driver for you; there is no add-on to install and no CRDs to author by hand. Declarative, scheduler-aware requests. Interfaces are advertised to Kubernetes as allocatable devices, so a pod that asks for one is placed on a node that can actually provide it, using standard Dynamic Resource Allocation (DRA) objects rather than vendor-specific annotations. A predictable interface lifecycle. The driver handles attach, release, and recovery as pods are rescheduled or restarted. A public IP address can be assigned directly to a secondary interface, configured at node pool creation time using IP tags. The pod's secondary interface talks to the outside world without going through the load balancer or any address translation layer. Both IPv4 and IPv6 addresses are supported on the secondary interface. What to plan around Interfaces are dedicated, not shared. When a NIC is attached to a pod, it moves into that pod's network namespace and is no longer available to the node or to any other pod. Sharing a secondary NIC across pods isn't supported in this release. Because of that, pod density on a multi-NIC node pool is bounded by the number of interfaces on the node. All interfaces must be attached to the same virtual network as the primary NIC. On a bring-your-own VNet cluster, different subnets within that VNet are supported, but different VNets are not, in this preview. On an AKS-managed VNet, secondary interfaces are currently limited to the same subnet as the primary NIC , since creating a new subnet on a managed VNet isn't supported yet. Each pod's secondary interface gets its own dedicated public IP, so plan node pool sizing around how many pods need a tagged public IP of their own. Public IP assignment is configured at node pool creation time through IP tags, so decide your IP range and tagging strategy before you provision the node pool. Kubernetes network policy is enforced on the primary interface only. Plan isolation for secondary interfaces at the subnet and NSG layer. Use Case 2: Multi-NIC nodes with your own NIC management “As a platform/networking engineer, I want to provision Kubernetes worker nodes with multiple network interfaces connected to different networks and use my own VPP, DPDK, or any custom routing logic to steer traffic at the node level, without attaching additional interfaces to pods.” This is the pattern for teams who already own their dataplane. The node is multi-homed, each interface lands on its own subnet, and your own software decides which traffic goes where. Pods keep a single CNI-assigned interface and stay unaware of the underlying topology. What you get Depending on the selected SKU size, you can configure nodes with multiple network interfaces. Full control, and full ownership of the additional nics. AKS provisions the interfaces and keeps them attached to the node. How traffic is steered across them is entirely yours to design, configure, operate, and support. That includes your routing rules, your userspace dataplane, and any troubleshooting of the forwarding path itself. The same-VNet constraint applies here too, secondary interfaces can span subnets, but not virtual networks. This applies to bring-your-own VNet clusters. On an AKS-managed VNet, secondary interfaces are restricted to the primary NIC's subnet for now. Both patterns start from the same node pool configuration. The difference is whether you stop there and manage the interfaces yourself, or let the DRANET hand them to your pods. How it works Multi-NIC on AKS starts with a single configuration step: you add secondary network interfaces to a node pool. AKS provisions the NICs on every VM in the pool and installs the DRANET driver alongside them. From there, what happens to those NICs depends on your workload. Reference a resource claim in your pod spec, and DRANET moves an interface into the pod Or Leave them on the node and steer traffic yourself with VPP, DPDK, or custom routing. Step 1: Provision the node pools with secondary NICs Secondary interfaces are declared when you create the node pool. The agent pool's network profile carries a secondaryNetworkInterfaces array, and each entry points at a subnet in the same virtual network as the primary NIC: "networkProfile": { "secondaryNetworkInterfaces": [ { "type": "Standard", "vnetSubnetId": "" } { "type": "Standard", "vnetSubnetId": "" } ] } AKS extends VMSS provisioning to attach those NICs to every VM in the pool. Add more entries for more interfaces, up to what the VM SKU allows. The array length is validated against the SKU at creation time, so a pool with mixed sizes has to be planned around the smallest one. The node is now multi-homed and the interfaces are visible on the host. If you are building for use case 2, this is where you stop. AKS provisions and keeps the interfaces attached to the node, and how traffic is steered across them, the routing rules, the userspace dataplane, the troubleshooting of the forwarding path, is yours to design, operate, and support. Step 2: Using AKS managed DRANET driver to hand an interface to the pod Once a node pool has secondary interfaces configured, and the cluster is using AKS-managed CNI (Azure CNI or Azure CNI Powered by Cilium), AKS automatically installs the DRANET driver as a DaemonSet, packaged and delivered through an AKS-managed Helm chart. There is nothing to deploy yourself and no CRDs to author by hand. If you're running a BYO CNI cluster, AKS still provisions the secondary NICs, but you're responsible for deploying DRANET (or your own driver of choice) yourself. The driver does three things: Discovers the additional interfaces present on each node. Advertises them to Kubernetes as allocatable DRA devices, published in a ResourceSlice. Manages the lifecycle: exclusive per-pod allocation, attachment, release, and recovery as pods move or restart. Inspect the DRANET deamonset, pods, and deviceclass using the following commands: kubectl get deviceclasses kubectl get daemonset -A kubectl get pods -A -o wide Now you can create a “ResourceClaimTemplate” that defines how each pod requests a device. apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: nic-dev-template spec: spec: devices: requests: - name: nic exactly: deviceClassName: standard-secondary-nic allocationMode: ExactCount count: 1 Configure the pod references the template, and the scheduler places it on a node that has a matching NIC available: apiVersion: v1 kind: Pod metadata: name: multi-nic-test spec: containers: - name: multi-nic image: nicolaka/netshoot resources: claims: - name: nic resourceClaims: - name: nic resourceClaimTemplateName: nic-dev-template A pod referencing a claim comes up with its usual CNI-assigned eth0 plus the allocated secondary interface, and you can confirm both from inside the container. When DRANET attaches a secondary NIC to a pod, that interface moves into the pod's network namespace and is no longer available on the node or to any other pod. It returns to the node's pool of available devices when the pod terminates. That gives you a clean isolation boundary and deterministic performance, with the trade-off that pod density on a multi-NIC pool is bounded by interface count, not just CPU and memory. For the full walkthrough including feature flag registration, more examples visit https://aka.ms/aks/multi-nic. Try it now Multi-NIC support for pods on AKS is available now in public preview. Start with the documentation for the full walkthrough: provisioning a node pool with secondary interfaces, defining a resource claim, and validating that both interfaces appear inside the pod. Documentation: https://aka.ms/aks/multi-nic Upstream project: DRANET on GitHub Preview is when your input can actually shape the feature. If you hit a limitation or have a use case we haven’t covered, comment below and share your feedback.

Speaking at NVIDIA GTC Berlin: Microsoft Sovereign Cloud and Sovereign AI

Fri, 09 Oct 2026 16:43:06 +0000

I’m excited to be speaking at NVIDIA GTC in Berlin, where I’ll be part of two sessions focused on Microsoft Sovereign Cloud and Sovereign AI. As organizations accelerate their adoption of AI, sovereignty is becoming increasingly important. Customers want to take advantage of cloud and AI innovation while maintaining the control, security, compliance, and resilience […] The post Speaking at NVIDIA GTC Berlin: Microsoft Sovereign Cloud and Sovereign AI appeared first on Thomas Maurer .

Azure Weekly Update - 9th October 2026

Fri, 09 Oct 2026 15:47:00 +0000

Nice selection of updates this week! 🔎 Looking for content on a particular topic? Search the channel. If I have something it will be there! 🤔 Due to the channel growth and number of people wanting help I no longer can answer or even read questions and they will just stay in the moderation queue never to be seen so please post questions to other sites like Reddit, Microsoft Community Hub etc. ▬▬▬▬▬▬ C H A P T E R S ⏰ ▬▬▬▬▬▬ 00:00 - Introduction 00:13 - New videos 00:49 - AKS bare metal on Ubuntu 01:43 - AKS Anyscale 02:23 - AKS NAT GW standardv2 default 03:00 - App Service Java 8,11 and 17 retirement 03:12 - ADE retirement 04:18 - Microsoft Dev Box retirement 04:52 - App GW WAF IPv6 05:20 - WAF exceptions 06:44 - API-M A365 integration 08:54 - PostgreSQL flexible in East US 3 09:06 - PostgreSQL Elastic major version upgrades 09:52 - Enabling the Bulk admin role for SQL Server on Linux 10:25 - PostgreSQL flexible & elastic Azure Backup support v2 11:39 - OneLake catalog table discovery 12:20 - SQL Server on Azure VM in Azure Bleu 12:41 - Azure HorizonDB additional regions 13:17 - Azure SQL DB always encrypted with Intel SGX enclaves retirement 13:41 - MAI Code 1.1 Flash local 15:56 - Close ▬▬▬▬▬▬ Want to learn more? 🚀 ▬▬▬▬▬▬ 📖 Recommended Learning Path for Azure 🔗 https://learn.onboardtoazure.com 🥇 Certification Content Repository 🔗 https://github.com/johnthebrit/CertificationMaterials 📅 Weekly Azure Update 🔗 https://youtube.com/playlist?list=PLlVtbbG169nEv7jSfOVmQGRp9wAoAM0Ks ☁ Azure Master Class 🔗 https://youtube.com/playlist?list=PLlVtbbG169nGccbp8VSpAozu3w9xSQJoY ⚙ DevOps Master Class 🔗 https://youtube.com/playlist?list=PLlVtbbG169nFr8RzQ4GIxUEznpNR53ERq 💻 PowerShell Master Class 🔗 https://youtube.com/playlist?list=PLlVtbbG169nFq_hR7FcMYg32xsSAObuq8 🎓 Certification Cram Videos 🔗 https://youtube.com/playlist?list=PLlVtbbG169nHz2qfLvPsAz9CnnXofhmcA 🧠 Mentoring Content 🔗 https://youtube.com/playlist?list=PLlVtbbG169nGHxNkSWB0PjzZHwZ0BkXZZ ❔ Questions? Maybe I answered it in my FAQ 🔗 https://savilltech.com/faq 👕 Cure Childhood Cancer Charity T-Shirt Channel Store 🔗 https://johns-t-shirts-store.creator-spring.com/ 👂 Enable the subtitles and from there you can translate to your native language via the auto-translate feature in settings! https://youtu.be/v5b53-PgEmI for a demo of using this feature. SUBSCRIBE ✅ https://www.youtube.com/channel/UCpIn7ox7j7bH_OFj7tYouOQ?sub_confirmation=1 #microsoft #azure #johnsavillstechnicaltraining #cloud

Azure SQL Data Sync After a Database Restore: Troubleshooting Leftover Sync Metadata

Fri, 09 Oct 2026 09:40:33 +0000

Recently, I worked on an interesting Azure SQL Data Sync issue that I thought was worth sharing with the community. The scenario looked straightforward at first: a database had been restored from another environment and was being configured as a Member database in a new Data Sync group. However, synchronization wasn't working as expected. The interesting part was not the new Sync Group itself. It was what the restored database had brought with it from its previous Data Sync configuration. The scenario The Member database was a restored copy of a database that had previously participated in another Azure SQL Data Sync group. After the restored database was configured as a Member in the new environment, synchronization wasn't working as expected. During troubleshooting, another important clue emerged. The restored database still had a history with Azure SQL Data Sync, so we needed to determine whether metadata and generated objects from its previous configuration were still present. This became one of the key areas of the investigation. Understand the Data Sync architecture first Before jumping into scripts, it's important to clearly distinguish the three database roles involved in Azure SQL Data Sync: Hub Database: The central database containing the application data being synchronized. Member Database: A database that synchronizes with the Hub. Sync Metadata Database: A separate Azure SQL Database containing Data Sync metadata and logs. Microsoft's documentation explains that Data Sync follows a hub-and-spoke topology and that the Sync Metadata Database contains Data Sync metadata and logs. This distinction became particularly important during this investigation because the initial diagnostic configuration wasn't pointing to the expected Sync Metadata Database. Troubleshooting approach Here is the troubleshooting flow we followed. Step 1: Run the Azure SQL Data Sync Health Checker One of the first tools I recommend for this type of investigation is the public Azure SQL Data Sync Health Checker : Azure SQL Data Sync Health Checker on GitHub [github.com] The tool validates whether metadata associated with the Hub and Member is in place and compares the scopes against information in the Sync Metadata Database. Importantly, the Health Checker repository states that it performs validation without changing Data Sync or user objects. The tool requires the relevant connection details for: Sync Metadata Database Hub Database Member Database The GitHub repository contains the current script and execution instructions. What we observed In our investigation, the initial Health Checker output included messages similar to: WARNING: dss schema IS MISSING! WARNING: TaskHosting schema IS MISSING! Invalid object name 'dss.syncgroup'. Invalid object name 'dss.userdatabase'. Those errors were important clues, but they needed to be interpreted together with the database roles. Microsoft's documentation states that the DataSync schema is used for system-created objects in Hub and Member databases, while the dss and TaskHosting schemas are used for system-created objects in the Sync Metadata Database. That distinction helped us recognize that we first needed to validate which database was actually being supplied to the Health Checker as the Sync Metadata Database. Lesson learned Before treating a missing dss or TaskHosting schema as corruption, first make sure you're actually connected to the Sync Metadata Database . That simple validation can save a lot of investigation time. Step 2: Check the Member database for Data Sync artifacts Once we had clarified the topology, the investigation moved to the restored Member database. Because this database had previously participated in Data Sync, we wanted to understand what Data Sync objects were still present. One of the queries used during troubleshooting was: SELECT name FROM sys.tables WHERE SCHEMA_NAME(schema_id) = 'DataSync' AND name NOT LIKE '%_tracking%'; We also inspected: SELECT * FROM DataSync.schema_info_dss; And, when checking the Member database's Data Sync scope information: SELECT * FROM DataSync.scope_info_dss; These checks helped us understand the Data Sync metadata state of the restored Member database and whether it still contained artifacts associated with its previous configuration. Why this matters Microsoft's current Data Sync best-practices documentation confirms that the DataSync schema is used for system-created objects in Hub and Member databases. So, when investigating a database restored from an environment where it previously participated in Data Sync, the DataSync schema is an important part of the investigation. Step 3: Consider the history of the restored database This was really the turning point in the investigation. Instead of treating the database simply as a "new Member", we started looking at it as: A restored database that had previously been provisioned for another Data Sync configuration. That's an important difference. When troubleshooting a restored database, ask early: Was this database previously part of another Azure SQL Data Sync group? If the answer is yes, the database's previous Data Sync state should be considered during the investigation. Step 4: Remove the Member before cleanup In our scenario, the remediation sequence was essentially: Remove the restored database from the current Sync Group. Clean up the previous Data Sync metadata from the restored Member database. Re-add the database as a Member. Trigger synchronization again. For the cleanup portion, we used the following publicly available repository: SQL Data Sync Cleanup Scripts on GitHub [github.com] The repository contains several scripts for different purposes, including: Data Sync complete cleanup.sql Data Sync cleanup hub or member.sql cleanup data sync object V2.sql The specific complete-cleanup script is available here: Data Sync complete cleanup.sql Important warning about the cleanup script Please do not treat this as a general-purpose Data Sync troubleshooting script . The script itself contains a very clear warning. It immediately cleans Data Sync-related objects associated with the database and says it should be used only for the scenarios specified in the script, including when advised by the support team during a support request. The repository also explains the different purposes of its cleanup scripts. For example, the complete-cleanup script has more restrictive usage guidance, while the Hub/Member cleanup and object cleanup scripts target different scenarios. My recommendation: use the Health Checker and read-only diagnostic queries first. Do not jump directly to metadata cleanup without understanding the database topology and existing Data Sync configuration. Step 5: Validate with one table After cleaning up the previous Data Sync artifacts, we didn't immediately assume that everything was resolved. Instead, we validated with a controlled test. A test table on the Member side was truncated, the synchronization was started again, and the table began synchronizing successfully. That provided the confirmation we needed that the previous Data Sync state of the restored Member was an important part of the issue. Root cause The troubleshooting pointed to the fact that the restored Member database had previously participated in another Data Sync configuration and retained Data Sync-related metadata/artifacts from that previous state. After cleaning up the old Data Sync state and reprovisioning the restored database as a Member, synchronization was successfully validated again. The important lesson for me wasn't simply the cleanup itself. It was recognizing that restoring a database does not necessarily mean you're starting with a clean Data Sync state . A practical troubleshooting flow For similar scenarios, I would approach the investigation in this order: Confirm the architecture Identify the: Hub Database Member Database Sync Metadata Database Run the Health Checker Use: Microsoft Azure SQL Data Sync Health Checker [github.com] Review its output before making changes. Inspect the restored Member Check whether Data Sync-related objects exist: SELECT name FROM sys.tables WHERE SCHEMA_NAME(schema_id) = 'DataSync' AND name NOT LIKE '%_tracking%'; Then, where applicable to the database's current state, inspect: SELECT * FROM DataSync.schema_info_dss; and: SELECT * FROM DataSync.scope_info_dss; Ask about the database history Was the database: restored from another environment? previously a Data Sync Member? previously associated with another Sync Group? That historical context can completely change the direction of the investigation. Consider cleanup only after understanding the environment The public cleanup scripts are available here: SQL Data Sync Cleanup Scripts [github.com] These scripts make changes to Data Sync objects and should not be the first troubleshooting step. Validate using a controlled test Once the environment has been correctly cleaned/reconfigured, validate synchronization on a controlled scope before assuming the entire configuration is healthy. My key takeaways This troubleshooting experience reinforced a few lessons for me. A restored database isn't necessarily a clean Data Sync database Restoring the application data doesn't mean you should ignore the database's previous synchronization configuration. Always distinguish Hub, Member, and Sync Metadata databases This is especially important when interpreting Health Checker output. The DataSync schema is associated with system-created objects in Hub and Member databases, while dss and TaskHosting are associated with system-created objects in the Sync Metadata Database. Use diagnostics before cleanup The Azure SQL Data Sync Health Checker is designed to validate Data Sync metadata and objects without making changes. That makes it a much better starting point than immediately removing objects. Database history matters One of my favorite questions after this investigation is now: "Was this database ever part of another Data Sync Group?" It's a simple question, but in restore or copy scenarios it can reveal an important part of the troubleshooting story. Be very careful with metadata cleanup The public cleanup repository itself provides specific guidance about when each script should be used, and the complete-cleanup script includes an explicit warning before execution. Always understand the environment and protect your data before performing destructive operations. One more important consideration: SQL Data Sync retirement There is also an important longer-term architecture consideration. Microsoft currently documents that SQL Data Sync retires on September 30, 2027 . Existing Sync Groups can continue operating until the retirement date, but Microsoft recommends migrating to alternative data replication and synchronization solutions before then. So, while troubleshooting existing Data Sync environments remains necessary, organizations using the service should also begin considering their migration strategy. References and useful tools Microsoft documentation Best practices for Azure SQL Data Sync [learn.microsoft.com] Troubleshooting tools Azure SQL Data Sync Health Checker [github.com] SQL Data Sync Metadata Cleanup repository [github.com] Data Sync complete cleanup.sql

Introducing the Native Confluent Cloud Connector Experience in Azure Cosmos DB!

Fri, 09 Oct 2026 07:00:28 +0000

Co-authored with Praveen Raja P Azure Cosmos DB already includes a powerful event foundation: change feed provides a durable, ordered record of item changes within each logical partition. It is ideal for reacting to operational data as it changes, building projections, and driving workflows directly from the database. Confluent Cloud adds a complementary event layer […] The post Introducing the Native Confluent Cloud Connector Experience in Azure Cosmos DB! appeared first on Azure Cosmos DB Blog .

Run Deterministic SQL Before Asking a Local LLM to Plan

Fri, 09 Oct 2026 07:00:00 +0000

“How many patients are there?” is not a semantic-search question. Retrieving six relevant patient chunks and asking a language model to infer the total would be fast, fluent, and wrong. It is also unnecessary: a database already knows how to count. Yet sending every structured question directly to text-to-SQL is not ideal either. Local planning adds latency, consumes scarce accelerator time, and introduces a probabilistic interpretation step for requests that often fit a small set of exact shapes. On a hospital server that may only have an integrated GPU - or only a CPU - that accelerator time is the system’s scarcest resource, and a question the parser can answer is capacity returned to the questions it cannot. Part 7 uses a different order: route structured intent, link one source scoped to the asking service line, parse the question deterministically into a typed query specification, bind it to that source’s schema, compile dialect SQL, and invoke the local planner only on a clean miss . The first version of this prototype implemented the deterministic step as SQL templates keyed on the development seed’s table names. That worked on one schema and on no other. This article describes the design that replaces it - a QuerySpec intermediate representation with a grammar, a binder, and a compiler - and is honest about status: the IR is the accepted target design, specified in plan 03, and the code that runs today is still the template matcher. Every emitted statement - deterministic or model-generated - still passes through the same AST policy, table allowlist, row bounds, cost preflight, read-only execution, and timeout controls. A deterministic parse is a planning shortcut, never a safety bypass. There is a privacy argument for this order as well as a correctness one. Beyond the residency rule that keeps the whole pipeline inside one facility, data-protection regimes generally require an impact assessment before high-risk processing begins, and regulators treat AI-powered clinical systems as exactly that. A count answered by SELECT count(*) puts no record content into a prompt at all, and a deterministic parse means no model saw the question’s data either. Data minimisation is easier to evidence in an impact assessment when whole classes of question never reach an inference engine - and when everything that does reach one is already inside the boundary Part 1 describes. The system and examples use synthetic health data. This is a prototype architecture discussion, not clinical advice, compliance guidance, or a claim that arbitrary natural language can be answered accurately. The reference implementation is in Rust, while the pattern can be implemented through the Foundry Local SDK Reference in C#, JavaScript, Python, or Rust; Part 2 provides all language links. Problem statement Semantic top-k retrieval cannot establish an exact count, complete grouping, or authoritative trend from an operational database. Asking a model to infer those results from selected chunks produces an answer that may sound precise while omitting records outside the retrieval window. Sending every structured question directly to an LLM-generated SQL path is also insufficient. Local planning consumes scarce inference capacity, adds latency, and can propose unsafe, overbroad, or schema-invalid statements. Prompt instructions alone cannot constrain database authority, and retries can silently expand both cost and behavior. The structured path must recognize deterministic question shapes first, then use a local planner only for genuine misses. It must do so against any relational hospital schema, not the one it was developed on. Every proposal must enter the same parsed safety envelope and bounded read-only executor, with typed fallbacks that preserve provenance rather than relabeling semantic retrieval as exact analytics. Because the whole pipeline is confined to one facility, the local planner is a scarce shared resource rather than an elastic service, which is a further reason to reach for it last. Success criteria Supported exact questions compile to reproducible SQL without an LLM call. The deterministic path contains no physical table or column names; those come from a per-source binding. Deterministic and model-proposed statements pass the same AST and allowlist checks. Execution enforces source scope, row caps, cost limits, read-only behavior, and timeouts. Model planning permits at most one bounded repair within the original deadline. Results expose SQL, rows, and the path taken; fallback paths remain visibly distinct and typed. Keep exact and semantic questions on different paths Narrative questions benefit from hybrid retrieval and grounded generation. Counts, groups, trends, rankings, and bounded listings should prefer structured execution. The router therefore follows a cheapest-first path: resolve cheap references (“her”, “that ward”, “same period”) from typed conversation focus, without a model; handle conversational and conversation-meta questions with anchored rules; attempt a deterministic QuerySpec parse - a successful parse is a structured routing decision; use lexical rules for remaining clear structured or semantic intent; call a small local classifier only for ambiguous or mixed requests; ask one bounded clarifying question when intent is clearly structured but a required slot is missing; and fail open to semantic retrieval if nothing above decides. A structured result does not mean “let the model choose any database.” The server selects the backend from binding coverage : live-source SQL is chosen only when a connected source has tables bound to the concepts the question mentions; otherwise aggregation over ingested copies; otherwise semantic retrieval. The fallback order is deliberate: live-source deterministic SQL, local model-planned SQL, constrained aggregation over ingested copies, then semantic retrieval. It preserves availability without presenting top-k retrieval as exact analytics. Stage 1: link a versioned schema, not raw imagination PostgreSQL, MySQL, and SQL Server form the External Clinical Databases group. Each remains an independent operational source. The system does not generate a cross-source federated query. A separate Internal DocumentDB Hybrid Store (documents + vectors + metadata/state) contains versioned schema cards as well as ingested records and application state. For every source, a catalog refresh introspects tables, columns, primary/foreign keys, bounded samples, and approximate profiles. It builds card text, embeds it locally with BGE-M3, writes a complete UUIDv7 catalog version, and then moves the active pointer. A failed refresh preserves the previous last-known-good catalog. Schema linking: embeds the question locally; restricts candidate cards to the tables the asking service line owns (plus shared concepts such as Patient and Encounter) when the question came through a service-line agent; ranks the remaining active cards, promoting explicit table names and administrator-defined aliases; chooses the source owning the strongest card; takes a bounded number of seed cards; and adds each seed’s outgoing one-hop foreign-key targets. An explicit mention cannot escape scope: a Maternity question that names the billing table gets a redirect to the Revenue agent, not a join. Incoming edges and recursive expansion are not automatic. That limitation matters: if the needed relationship is visible only in the reverse direction, the deterministic binder or planner may miss. The correct response is a miss or fallback, not invented schema. Versioned cards make the planning input inspectable. They are still a bounded copy: samples and profiles are not authoritative statistics, and source drift between refreshes can invalidate assumptions. The cards also feed a second artifact that the rest of this article depends on: a schema binding . At catalog time a binder scores every table against a fixed set of hospital entity concepts - Patient, Encounter, Admission, Delivery, Prescription, Bill, and so on - using normalized name tokens, column vocabulary, required roles, BGE-M3 similarity between the card and the concept description, and foreign-key shape. Every column receives a role : PatientRef, EventTime, StartTime/EndTime, Status, Amount, Quantity, Code, Flag, and a few more. Low-cardinality enum columns keep their observed values. Administrators can override any concept or role and the binding is rebuilt. Part 1 describes why this exists; here it is the thing the deterministic path binds to . Stage 2: templates keyed on table names do not travel The first deterministic compiler in this prototype was a set of SQL templates. Each recognized a closed question frame and emitted SQL for the development seed: patients, encounters, deliveries. It passed its benchmark and it was still the wrong shape, because it fused three concerns that change at different rates: Concern Changes when Should live in Language → intent someone phrases a question differently a grammar Intent → physical columns the system is installed at a different hospital the per-source binding Physical → SQL text a new database dialect is added a compiler A template that says COUNT(*) FROM deliveries WHERE delivery_mode = 'caesarean' has all three baked into one string. Move it to a hospital whose table is OB_Delivery and whose column is mode_of_delivery, and every template must be rewritten in Rust. Add a question shape, and every hospital needs a release. The design that replaces it separates the concerns with a typed intermediate representation. The QuerySpec IR The grammar’s output is a QuerySpec. Trimmed from the plan: pub struct QuerySpec { pub subject: Subject, // the concept rows are drawn from; table filled at bind pub shape: Shape, pub measures: Vec, // empty for List / Lookup pub dimensions: Vec, // GROUP BY pub filters: Vec, // AND-ed pub time: Option, // range on EventTime/StartTime + optional bucket pub order: Vec, pub limit: Option, pub joins: Vec, // resolved at bind time from FK paths pub projection: Vec, // List / Lookup display columns pub provenance: SpecProvenance, // which rule fired, which focus substitutions } pub enum Shape { Scalar, Grouped, Trend, TopN, List, Lookup, Rate, Exists } /// Logical column: concept + role (+ optional name hint). Resolved to table.column at bind. pub struct ColumnRef { pub concept: EntityConcept, pub role: ColumnRole, pub name_hint: Option, pub physical: Option<(String, String)>, } Nothing in a freshly parsed QuerySpec names a table or a column. A ColumnRef says “the EventTime of Delivery” and leaves physical empty. Shape is the closed set of result shapes the compiler knows how to emit; it maps back onto the existing QueryIntent the router and UI already use, so the contract above the IR does not change. A grammar of slot-filling rules The grammar is a small ordered set of rules. Each states the anchor tokens it consumes and the slots it fills; a question parses only when a rule matches and every remaining token is in a filler allow-list (“the”, “of”, “show me”, “how many”, “currently”). That full-consumption requirement generalizes the rule the old templates already used for identifier lookups: extra qualifiers are a miss, not a guess. Rule Pattern (informal) Example Shape R1 how many | count | number of [filters] [time] [by ] “how many caesarean deliveries last month by ward” Scalar / Grouped R4 per | by or trend | over time “admissions per month this year” Trend R5 which | who had | performed | prescribed the most “which surgeon performed the most surgeries” TopN via FK path R7 what is our where the rate word is an enum value or flag “what is our no-show rate” Rate R15 without | missing | no “admissions without a bed assignment” anti-join filter Rules compose. R1 plus a location modifier plus a status modifier plus a time phrase yields “how many patients are currently admitted in ICU” as one QuerySpec: subject Admission, shape Scalar, a filter on the WardRef join’s name column, a filter that reads EndTime IS NULL or a Status enum value, and no time bucket. Concept resolution is vocabulary-driven: a noun phrase maps to a concept when it matches the concept’s singular, plural, or synonyms, a bound table name, or an admin alias. Enum values become filters through the binding’s observed values, so “caesarean” resolves to (delivery_mode, caesarean) on this hospital and to whatever the equivalent column is called on the next. A dimension such as “by ward” resolves through the subject’s WardRef role to the ward table’s name column, or to a Location column when the schema has no ward table. Domain predicates live in roles Some phrases carry clinical or operational meaning that is not a literal value in any column. The design keeps them in a fixed predicate table expressed only in roles and name hints: Phrase Concept Predicate low birth weight Newborn Measure(name_hint: weight) < 2500, unit inferred from the column name no-show Appointment Status enum = no_show expiring within N days StockBatch / License / BloodUnit EventTime(name_hint: expir) BETWEEN now AND now + N days outstanding / unpaid Bill Amount(name_hint: due|balance) > 0 or Status enum ∈ {billed, partial} length of stay Admission Duration(name_hint: los) else EndTime - StartTime If the hospital’s schema has no column playing the required role, the predicate is unbound and the parse reports a missing slot. It does not silently pick a nearby column. Bind errors become questions, not guesses bind resolves every ColumnRef against the source’s binding: the subject’s table, each role on that table or a one-hop foreign-key neighbour (two hops for dimensions only), and the patient path when the question names a patient. It fails typed: NoSubject, NoRole(role), NoPath(a, b), Ambiguous(role, candidates). The router turns a missing subject into one clarifying question - “Which records do you mean: appointments, admissions, or surgeries?” - and turns Ambiguous into a clarify whose options are the candidate columns. The rule is at most one clarification per turn and never two in a row; the second time, the system falls through to semantic retrieval rather than interrogating the user. The governing principle of the old templates survives intact: A false negative is acceptable; a false positive is not. A miss moves to the local planner. A guessed binding can execute successfully and return the wrong answer with high confidence. The compiler owns the dialect compile takes a bound QuerySpec and a SourceKind and emits SQL text plus a one-sentence explanation (“Counted deliveries with delivery_mode = caesarean between 2026-08-01 and 2026-08-31, grouped by ward”). Identifiers are always quoted for the dialect; values are inlined as escaped literals and the validator re-parses everything, so no user text is spliced outside a literal. Time buckets compile to DATE_TRUNC on PostgreSQL, DATE_FORMAT on MySQL, and DATETRUNC or DATEFROMPARTS on SQL Server; durations to EXTRACT(EPOCH …), TIMESTAMPDIFF, or DATEDIFF; anti-joins to NOT EXISTS. Relative ranges are computed server-side and inlined as ISO literals so the SQL is self-contained provenance. A shape the dialect cannot express - a median on MySQL - is a compile miss that goes to the planner, not an approximation. Deterministic output can still be wrong because code has bugs or metadata can be stale. It therefore enters exactly the same validator and executor as model output. Stage 3: the local LLM speaks the same IR If the grammar cannot parse the question, the server obtains the planning model role and asks Foundry Local to fill a QuerySpec - a tool call whose JSON schema is the IR, with concepts and roles as enums and physical names forbidden. The proposal then goes through the same bind and compile as a grammar parse. This changes what a bad proposal can do. A small local model is markedly more reliable filling a typed schema than writing dialect SQL, and a QuerySpec that names a concept the binding lacks, or a role the subject does not have, is rejected by bind before any SQL exists and before any database is touched. Only if the IR path fails does the design fall back to the existing raw-SQL planner as a last resort. Foundry Local is the local generative runtime. It does not execute SQL and it does not decide the security policy. The model’s output is untrusted data in either form. A single planning deadline covers the first plan and at most one repair. That prevents “retry until something executes,” which can turn safety failures into prompt-driven exploration. The current raw-SQL planner already enforces that shape; the IR planner keeps the same deadline and repair budget: let deadline = Instant::now() + plan_timeout; let mut repaired = false; let mut proposal = timeout_at(deadline, plan_sql(...)).await??; let mut sql = match validate_sql(&proposal.sql, dialect, cap, allowed) { Ok(sql) => sql, Err(error) => { repaired = true; proposal = timeout_at( deadline, plan_sql_repair(..., &proposal.sql, &error.to_string()), ).await??; validate_sql(&proposal.sql, dialect, cap, allowed)? } }; If first execution fails and no validation repair was used, the single repair can address that execution error. The repaired statement is parsed and validated again. There is never an unbounded autonomous loop. This is a practical local-inference use: reserve probabilistic planning for the long tail while common exact requests stay fast and reproducible. The Foundry Local quickstart demonstrates local model lifecycle and inference; in this architecture, those capabilities sit behind a server-owned policy boundary. Stage 4: enforce policy on the parsed AST String checks alone are not a SQL sandbox. The validator parses according to the selected source dialect and requires exactly one query statement. It rejects DDL, DML, locking clauses, relations outside the linked-table allowlist, and dangerous function or text signatures such as sleep, file access, dynamic SQL, OPENROWSET, or XP_CMDSHELL. It then normalizes from the AST and enforces an outer row bound: PostgreSQL and MySQL receive a constant LIMIT, inserted or clamped. SQL Server receives a constant, non-percent, non-ties TOP; unsupported outer set operations decline. The connector applies a second result cap during execution. let validated = validate_sql( proposed_sql, source_kind, config.nl2sql_max_rows, &linked_tables, )?; let (columns, rows) = run_select( &db, &config, source_id, &validated.sql, ).await?; Table names come from the linked schema cards, restricted to the service line’s scope. User literals enter only through the grammar’s typed filters or remain part of model output subjected to the parser and policy. Deployment should still use a least-privileged, read-only source account: application validation and database permissions are complementary controls. Stage 5: preflight cost and bound execution Before execution, connectors attempt an EXPLAIN or equivalent estimate when cost gating is enabled. A successful estimate above the configured maximum is rejected. If estimation itself fails, the current prototype logs the failure and continues to bounded execution. That fail-open choice is a tradeoff, not an invisible detail. Availability is preserved, but a broken estimate cannot enforce the cost threshold. The remaining layers - AST policy, row cap, database timeout, Tokio timeout, and read-only credentials - still apply. Execution returns columns and exact rows. For small results the server produces a deterministic summary rather than making a second narration-model call. The persisted result keeps source_id, executed SQL, columns, rows, the QuerySpec that produced them, and a provenance record listing each rung attempted and whether it hit or missed, so the UI can show the evidence type and the path directly. This architecture avoids fake capabilities. It does not promise that the system can answer arbitrary relational questions, that every planner query will be performant, or that EXPLAIN guarantees safe runtime. It promises a bounded attempt under explicit controls. Stage 6: fall back without changing the truth claim A final SQL failure does not become a fabricated SQL answer. The next path is a constrained aggregation or listing over active records in the Internal DocumentDB Hybrid Store, restricted to the same service-line scope. Where the subject table has been ingested, the bound QuerySpec translates directly into the aggregation specification - count, group, bucket, filter - without a model; otherwise the model proposes a typed specification and Rust validates fields and builds the pipeline. Chunked rows are deduplicated by row_pk before aggregation, preventing chunk count inflation. That result describes the latest successfully ingested snapshot, not necessarily current source state. If structured aggregation also fails, the system uses hybrid semantic retrieval and grounded generation, filtered to the same tables. The answer now carries passage citations rather than SQL provenance and must not claim exact whole-database counts. “Bounded failure” is defined precisely in the design: a parse miss, bind error, validation error, connector error, timeout, cost rejection, or an empty result on an existence question. An empty result on a list or grouping is a hit with an honest “none”. Falling back there would silently swap an exact answer for a fuzzy one. The evidence changes with the backend: Path Data freshness Evidence Live-source SQL Source state at execution Source ID, validated SQL, columns, exact rows DocumentDB aggregation Last active ingest generation Validated spec, rows, generated pipeline Semantic RAG Last active ingest generation Ranked passages and citations The router recognizes hybrid cohort-plus-narrative intent. In the target design the cohort is a QuerySpec forced to a list shape, its row keys become an explicit retrieval filter, and narration receives both the cohort summary and citations. The current build does not yet run that path; hybrid-class requests fall back to ordinary semantic retrieval. Useful deterministic patterns - and deliberate refusals A robust grammar documents what it declines as carefully as what it accepts. R1 can accept “How many patients are there?” and decline “How many active patients are there?” unless “active” resolves to a Status enum value or Flag role on the bound Patient table. R4 can accept a closed trend frame and decline a subject with no EventTime. R5 compiles only when the binding has a foreign-key path from the subject to the dimension concept. Follow-ups are handled by focus, not by re-parsing. The last QuerySpec is kept in typed conversation state; “and by ward?” mutates its dimension, “only caesareans” adds a filter, “as a percentage” changes the shape to Rate. Each mutation is a normal QuerySpec that binds and compiles like any other, and none of it calls a model. General coreference remains outside the claim. Tests should cover positive and refusal fixtures against more than one binding: assert_shape("How many patients are there?", &dev, Shape::Scalar); assert_shape("How many patients are there?", &alt_schema, Shape::Scalar); // PatientMaster assert_no_parse("How many active patients are there?", &dev_without_status_role); assert_no_parse("Delete all patients", &dev); assert_bind_error("admissions by ward", &schema_without_ward_ref, BindError::NoPath); A high refusal rate can be healthy if fallback is safe and observable. Tradeoffs and anti-patterns A grammar and binder require maintenance too, but of a different kind. Phrasings, filler lists, predicate definitions, and dialect rules are documented and tested once; a new hospital is a binding to review, not code to write. First-match semantics still mean a broad rule can shadow a safer specialized one, so rule order is part of the specification. Binder confidence is a heuristic; the design requires the dev seed and a second, differently named synthetic schema to bind correctly without overrides, and treats an admin override as the normal fix when a real schema binds badly. The local planner covers more language but adds latency and uncertainty. Schema linking limits prompt size and table access, but directional one-hop expansion can omit a necessary relationship. One repair improves resilience without creating an open-ended agent. Avoid these anti-patterns: using top-k semantic retrieval for exact totals; executing deterministic SQL without the shared validator; naming physical tables or columns anywhere in the deterministic path; trusting model-generated table names, or letting the model emit SQL when it could emit a typed spec; letting the model choose among operational sources without server policy; accepting extra unconsumed words in a grammar rule; guessing a column when a role is missing instead of asking or missing; retrying planning until some query runs; presenting a DocumentDB snapshot result as live-source data; claiming arbitrary query support or guaranteed performance. Prototype status Implemented today: tiered structured intent; one-source schema linking; versioned last-known-good schema cards; deterministic SQL templates before the model; local TextToSql planning on miss; dialect-aware AST validation; linked-table allowlists; read-only-only policy; limits; EXPLAIN cost preflight; connector and async timeouts; one repair within one deadline; SQL provenance; fallback to constrained DocumentDB aggregation and then semantic RAG. The committed A-series benchmark of ten exact questions on the synthetic seed resolves 10/10 through the deterministic templates. Planned and specified, not yet in code: the QuerySpec IR, grammar, domain predicates, binder, per-dialect compiler, model fallback in the same IR, service-line-scoped linking, the single executor with a provenance event, and focus-driven follow-up mutation (plans 01–04, 06). The design’s acceptance gates - A-series unchanged, a broader golden suite parsing on both the dev seed and a differently named synthetic schema, and zero physical names in the IR module - are targets, not results. Current limits include PostgreSQL-only specialized healthcare templates, directional one-hop relationship expansion, bounded rather than authoritative catalog samples, fail-open estimate errors, no arbitrary multi-hop or free-form aggregate guarantee, and no production performance certification. The recorded prototype evaluation uses synthetic data; deterministic benchmark passes do not validate the local planner’s quality. Key takeaways Route exact questions away from semantic top-k retrieval. Link one source, scoped to the asking service line, and a bounded versioned schema before compiling anything. Separate grammar, binding, and compilation so phrasing, hospital, and dialect can change independently. Prefer a deterministic typed parse and treat an unbound slot as a question or a miss, never a guess. Use the local LLM only for the long tail, ask it for the same typed spec, and allow one bounded repair. Apply the same AST, allowlist, row, cost, timeout, and read-only controls to every query. Preserve backend-specific provenance and freshness claims through fallback. Continue the series Previous: Part 6 - Streaming grounded chat to Desktop App and Mobile App Next: Part 8 - Bounded Local Agentic Patterns for Clinical RAG Learn more on Microsoft Learn What is Foundry Local? Get started with Foundry Local Foundry Local SDK Reference - Rust on Windows Design and develop a RAG solution The code behind this series is open source: github.com/kevin-gatimu/onprem-health-rag . It is a synthetic-data research prototype, not a clinical or compliance-ready system - issues and corrections are welcome.

Azure CLI on macOS got security upgrade: native broker authentication

Fri, 09 Oct 2026 04:40:50 +0000

Why we built this If you manage Azure resources from a Mac today, az login opens a browser tab, you sign in, and a token comes back to the CLI. That's worked well for a long time. As security requirements become more stringent, many enterprise organizations are adopting secure authentication brokers to strengthen identity protection and reduce authentication-related risks. Many organizations require broker-based authentication as a matter of security policy. A broker is the operating system's own credential broker — on Windows this is the Web Account Manager (WAM), and it's what lets az login reuse your existing signed-in Windows account instead of opening a browser every time. Depending on the broker, device configuration, and policies applied by the organization, broker-based authentication can provide: Device-bound refresh tokens , which help protect tokens from exfiltration and misuse Support for Conditional Access and device compliance checks where those capabilities are configured and available Single sign-on using accounts known to the operating system , reducing repeated credential prompts Azure CLI has supported broker authentication on Windows for a while. Beginning with Azure CLI 2.91.0 , organizations with stringent security requirements can also use broker-based authentication with Azure CLI on macOS. What changed Beginning with Azure CLI 2.91.0, broker-based authentication is available in preview on macOS. The feature uses MSAL's native macOS broker support and is disabled by default, so you remain in control of when to enable it. After you opt in and run az login, Azure CLI opens a native macOS account picker instead of starting the sign-in flow in a browser. You can select an account already known to the broker or add another account. If a compatible broker isn't available, Azure CLI falls back to the existing browser-based sign-in flow. How Homebrew Cask supports broker authentication The core MSAL library is open source, but the macOS broker runtime is not . It is subject to strict internal compliance and intellectual property protection requirements and must also satisfy Apple-specific requirements such as notarization. Azure CLI is now available through Homebrew Cask, a supported installation method that can accommodate these requirements and support broker-based authentication on macOS. The familiar package name continues to work for new installations: brew update brew install azure-cli You can also select the Cask explicitly: brew update brew install --cask azure-cli We tested the migration on a Mac that had Azure CLI 2.90.0 installed through the former Homebrew Formula. After brew update, Homebrew detected that azure-cli had moved to homebrew/cask, unlinked the existing Formula, downloaded Azure CLI 2.91.0 or later , and linked the az executable and shell completions from the Cask. The final output confirmed: azure-cli was successfully installed! azure-cli has been moved to homebrew/cask. The existing keg has been unlinked. Homebrew detects the package migration, installs Azure CLI from Cask, and preserves the az command. Homebrew also recommended removing the old Formula record when convenient: brew uninstall --formula --force azure-cli This means scripts that use brew install azure-cli can continue to use the same package name. If you previously used the Azure CLI preview tap and Homebrew still resolves stale Formula metadata, remove that tap and retry: brew untap azure/azure-cli brew update brew install azure-cli What the broker sign-in experience looks like Install Azure CLI 2.91.0 or later and make sure a compatible authentication broker, such as Microsoft Company Portal, is available on your Mac. Enable broker-based authentication: az config set core.enable_broker_on_mac=true az account clear You can confirm the setting with: az config get core.enable_broker_on_mac 3. Start a new sign-in: az login 4. Azure CLI opens the native single sign-on account picker. Select an existing account and choose Continue or use the add-account button to sign in with another account. After broker authentication is enabled, az login opens the native account picker instead of starting in a browser. 5. Run az account show to confirm that you're signed in with the expected account and tenant. The broker changes how Azure CLI acquires credentials; it doesn't change Azure CLI's subscription or tenant selection model. If your account belongs to multiple tenants, you might still need to select the intended tenant explicitly: az login --tenant To opt out and return to browser-based authentication: az account clear az config set core.enable_broker_on_mac=false az login If a compatible broker isn't installed or available, Azure CLI automatically falls back to browser-based authentication. What's next This is one part of a broader push to bring Azure CLI's macOS experience up to parity with Windows and Linux — including packaging improvements (to keep pace with Apple's tightening notarization requirements). If you run Azure CLI on macOS in an enterprise environment, we'd love to hear from you — file feedback or ask questions at Azure/azure-cli on GitHub . References Install Azure CLI on macOS Sign in with an authentication broker on macOS Azure CLI issues on GitHub

Optimizing Oracle-to-Power BI Performance and the Path to Modern Analytics

Fri, 09 Oct 2026 01:46:15 +0000

Organizations frequently rely on Oracle databases for large-scale operational workloads while using Microsoft Power BI as their enterprise analytics and visualization platform. Although connecting Power BI directly to Oracle is fully supported, performance can become challenging as datasets grow into the millions of rows. A recent enterprise scenario involving millions of Oracle records illustrates an important principle: Oracle-to-Power BI performance should not be attributed to a single component without first isolating the entire retrieval path. This article provides a practical framework for optimizing that architecture today, while also examining how Microsoft Fabric Mirroring can provide a different data-access pattern for future analytics workloads. The Performance Challenge Consider an Oracle environment containing approximately 15 million records. Testing showed substantially different behavior depending on the client used to retrieve the same Oracle data: A direct Oracle query executed through TOAD returned millions of rows in about eight minutes . Tableau connected to the same Oracle table from the same laptop and refreshed millions of rows in 20 to 30 minutes . Power BI Desktop, however, continued processing for multiple hours before the operation was terminated by network or database controls. Importantly, the Power BI query did not contain additional Power Query transformations. The customer was directly executing SQL and loading the resulting data. This is an extremely useful diagnostic comparison because it demonstrates that Oracle is capable of returning the underlying dataset considerably faster than the Power BI test. It does not , however, prove that the Power BI Oracle connector itself is the single root cause. Performance Is a Pipeline, Not a Single Component Oracle-to-Power BI performance involves several layers: A bottleneck at any one of these layers can affect overall refresh or query performance. Therefore, the first architectural principle is: Measure every layer before attempting to tune the entire solution. A troubleshooting exercise should evaluate: Oracle server-side execution time SQL execution plan Oracle provider/client behavior FetchSize behavior Network transfer Power Query evaluation Query folding Power BI model processing Report design Gateway behavior when the Power BI Service is introduced This approach avoids prematurely concluding that Oracle, Power BI, the gateway, or the connector is inherently responsible for the slowdown. Start With the Oracle Provider Power BI currently provides two important approaches for Oracle connectivity. Built-in Oracle provider Modern versions of Power BI Desktop include Microsoft's bundled Oracle Managed ODP.NET provider. This reduces the dependency on separately installing Oracle client software. For environments using the built-in provider, testing should be performed with a current Power BI Desktop release because provider behavior and defaults can change between releases. Oracle Client for Microsoft Tools Oracle Client for Microsoft Tools, or OCMT , remains another supported option. OCMT configures Oracle Data Provider for .NET and can therefore be tested independently from the built-in provider. This gives architects a useful isolation mechanism: Test A: Built-in Oracle provider vs. Test B: OCMT provider. Use the same: workstation SQL statement Oracle database table credentials network path expected row count Changing several variables simultaneously makes the results considerably harder to interpret. Understand FetchSize One of the most important areas identified during troubleshooting is FetchSize. FetchSize controls how much data the Oracle provider retrieves during each fetch operation. For large datasets, a small FetchSize can require many retrieval operations, increasing overhead. Increasing FetchSize allows the provider to retrieve more data at a time and may improve throughput. However, FetchSize tuning should be tested independently from the choice of Oracle provider. Switching to OCMT, for example, does not by itself demonstrate whether FetchSize tuning improves performance. Benchmark the same SQL and dataset using consistent test conditions and compare elapsed time and throughput. FetchSize controls how much Oracle data the provider pulls back in each retrieval batch. Think of FetchSize like the size of a delivery truck. Imagine Power BI needs to retrieve a very large dataset from Oracle. Small FetchSize: Oracle → 📦 → Power BI Oracle → 📦 → Power BI Oracle → 📦 → Power BI Oracle → 📦 → Power BI ...many retrieval operations Larger FetchSize: Oracle → 📦📦📦📦📦 → Power BI Oracle → 📦📦📦📦📦 → Power BI ...fewer retrieval operations The idea is simple: FetchSize determines how much data the Oracle provider fetches at a time. Examine Oracle Data Types FetchSize is not the only provider consideration. Schema matters. A troubleshooting package should include the table DDL rather than only a list of column names. Pay particular attention to large-object types such as: BLOB CLOB Large-object columns may materially change retrieval behavior and can make simply increasing FetchSize insufficient. Therefore capture: complete table DDL column names Oracle data types row width presence of BLOB/CLOB columns expected total result size Do not optimize FetchSize without understanding the shape of the data being transferred. Filter Rows and Columns as Early as Possible Probably the most universally applicable Power Query optimization is also one of the simplest: Do not retrieve data you do not need. Instead of retrieving every row and column and filtering afterward, reduce the dataset at Oracle whenever possible. Good Oracle SQL should therefore: select only required columns apply restrictive predicates at the source aggregate at Oracle where appropriate avoid unnecessary data transfer This matters substantially when Power BI and Oracle are separated by a network boundary. Preserve Query Folding Power Query query folding allows Power BI transformations to be translated back into SQL executed by the relational source. For relational sources such as Oracle, maintaining folding can substantially reduce the amount of work performed by the Power Query mashup engine. The preferred pattern is: Where practical: filter early remove unnecessary columns early avoid transformations that unexpectedly break folding inspect where folding stops push relational operations back into Oracle For DirectQuery , folding is particularly important because the source remains part of the interactive report-query path. Be Careful With Native SQL and Incremental Refresh Native SQL can be extremely valuable for troubleshooting. Running the same targeted SELECT statement through Power BI that is executed directly against Oracle creates a useful A/B test. It helps isolate questions such as: Is Oracle itself taking a long time? Is Power BI generating a different query? Is additional processing happening after Oracle returns the data? Is the retrieval/provider layer adding significant latency? However, architecture matters. Power BI guidance warns that later Power Query steps cannot necessarily fold after a native SQL query, and native SQL has important implications for incremental refresh. Therefore, native SQL is useful both as an optimization technique in some architectures and as a diagnostic isolation technique , but it should not automatically be substituted for a well-folded Power Query design. Prefer Import for Traditional Oracle BI Workloads If the business does not require near-real-time data, Import should generally be evaluated before DirectQuery for large Oracle analytical workloads . With Import : The latency of Oracle, networking, and the provider is mostly experienced during refresh rather than repeatedly during user interaction. This usually provides a more predictable interactive experience. DirectQuery produces a different dependency chain: As a result, source latency can become report latency. Use DirectQuery when its architectural benefits are required, rather than simply because the source database supports it. Make Incremental Refresh Truly Incremental Import does not necessarily mean repeatedly loading the entire Oracle dataset. For large fact tables, incremental refresh should be evaluated so that only required partitions are refreshed. However, there is an important condition: RangeStart and RangeEnd filtering needs to be pushed back to Oracle. If partition filters do not fold, Power BI can end up retrieving considerably more source data than expected before applying the filtering. Therefore incremental refresh testing should verify that the Oracle query generated by Power BI contains the expected predicates. Treat the Gateway as Its Own Performance Layer Once the workload moves into the Power BI Service, however, the on-premises data gateway becomes another measurable component. For production deployments examine: gateway version Oracle provider/client version CPU memory network proximity to Oracle refresh concurrency DirectQuery concurrency competing workloads Where necessary, large refresh workloads and latency-sensitive DirectQuery workloads can be isolated onto different gateway resources. Do not diagnose gateway performance from a Power BI Desktop test where the gateway is not involved. Optimize DirectQuery If It Cannot Be Avoided Sometimes Import is not viable because users require data with very low latency. If Oracle must remain behind DirectQuery, reduce unnecessary work at every level. At Oracle index frequently filtered columns appropriately review execution plans select only necessary columns reduce returned rows avoid unnecessarily expensive calculations In Power Query maintain query folding push filtering to Oracle minimize transformations requiring local evaluation In the semantic model use efficient dimensional modeling avoid unnecessary high-cardinality columns consider aggregation strategies where appropriate In reports limit visual density use selective filters avoid generating unnecessary simultaneous source queries test with realistic user concurrency DirectQuery performance needs to be assessed as an end-to-end architecture, rather than as an individual SQL benchmark. Collect Diagnostics Before Declaring a Root Cause For difficult Oracle performance cases, establish a repeatable diagnostic package. Capture: Oracle database version execution plan SQL execution duration table DDL data types row count approximate returned data size Provider built-in provider versus OCMT provider/client version FetchSize configuration Power BI Power BI Desktop version generated SQL Query Diagnostics Mashup traces Applied Steps or M code total execution time Network Oracle-to-client path throughput latency connection interruptions or timeouts Comparison clients If Tableau or another Oracle client appears dramatically faster, reproduce the same SQL, same columns, same records, same database and preferably the same machine . Only then does the comparison become a useful engineering benchmark. Future Architecture: Oracle Mirroring in Microsoft Fabric Optimizing the direct Oracle connection solves one class of problem. Microsoft Fabric Mirroring provides a different architecture altogether. Instead of repeatedly placing Oracle in the analytical query path, Fabric can continuously replicate Oracle changes into OneLake. Conceptually: Fabric Mirroring uses Oracle LogMiner to capture changes and maintain an analytical copy in OneLake. This separates many downstream analytical reads from the operational Oracle database. The key architectural advantage isn't simply "a faster connector." The advantage is decoupling analytics from the operational database . Recommended Architecture Decision Tree Requirement: traditional BI with scheduled freshness Use: Oracle → Import → Power BI semantic model. Then optimize: FetchSize provider query folding source-side filtering incremental refresh Requirement: operational or near-real-time reporting where Oracle must remain the source Evaluate: Oracle → DirectQuery → Power BI. But aggressively optimize: Oracle SQL execution plans query folding visual density provider configuration concurrency gateway architecture Requirement: enterprise analytics with frequent Oracle changes and growing BI/AI requirements Evaluate: Oracle → Fabric Mirroring → OneLake → Fabric / Power BI. This reduces repeated analytical pressure against the operational Oracle environment and creates a reusable analytical data foundation for additional workloads. A Practical Troubleshooting Sequence A useful Oracle-to-Power BI performance investigation can be organized into five phases. Phase 1: Establish the Oracle baseline Execute exactly the same query directly against Oracle. Record: SQL → rows → bytes → execution time Phase 2: Isolate the provider Run the same dataset through: Built-in Oracle provider and OCMT. Record the results independently. Phase 3: Test FetchSize Test controlled FetchSize values while holding every other variable constant. Measure throughput rather than relying on subjective impressions. Phase 4: Optimize Power Query Validate: query folding source filtering column projection transformations incremental refresh behavior Phase 5: Decide whether the architecture itself should change If extremely large Oracle datasets must continually feed analytical workloads, consider whether repeatedly querying Oracle remains the appropriate long-term design. At that point, Fabric Mirroring becomes an architectural discussion rather than simply another troubleshooting step. Final Takeaway Oracle-to-Power BI performance problems should not immediately be categorized as an Oracle problem, a Power BI problem, or a gateway problem. They are usually best investigated as a data retrieval pipeline . For existing Power BI architectures, the strongest optimization sequence is: Efficient Oracle SQL For the longer term, Microsoft Fabric Mirroring changes the architecture: Oracle becomes the operational system of record while OneLake becomes the analytical data plane. That separation can be particularly valuable as organizations expand from traditional Power BI reporting into broader Fabric analytics, data engineering and AI workloads.

How software companies can reach more SMB customers through Microsoft Marketplace in the age of AI

Fri, 09 Oct 2026 00:25:22 +0000

Publishing an offer on Microsoft Marketplace creates a starting point for reaching more customers and scaling growth; the opportunity goes well beyond getting listed. For software companies, Marketplace can create a path to reach more customers and scale revenue, particularly in the SMB market. Micro, small, and medium enterprises (MSMEs) account for 90% of companies globally and 70% of the world’s employment, according to World Bank Group and International Finance Corporation (IFC) data. 1 For software companies, this creates a significant opportunity to serve small and medium businesses with solutions that fit how they operate. These businesses often have lean teams, limited procurement resources, and a preference for self-service experiences that help them evaluate, purchase, and deploy technology efficiently. The age of AI is accelerating the opportunity for software companies to reach and serve SMBs. Software companies are moving beyond a simple Marketplace listing, building AI-powered products designed for how SMBs buy, deploy, and scale today. Founded in 2002, Ntegral was a traditional systems integrator, deploying client technology solutions one contract at a time. In 2021, the company began shifting its business model from primarily delivering services to bringing its own software solutions to market through Microsoft Marketplace. At UP LIVE Reston, Ntegral’s President and CTO, Dexter Hardy, will share more about what that shift meant in practice, including how Ntegral adapted its approach to products, sales, and growth. The change expanded Ntegral’s reach. Dexter has called Microsoft Marketplace "a real game changer" for the company, which now offers 300+ enterprise solutions with deployments in more than 150 countries. 2 Dexter described Marketplace as an important part of Ntegral’s growth strategy, helping the company expand its reach while, in his words, allowing Ntegral “to stay lean, focus on our expertise,” as it entered new markets. 🎯A session worth your time Scaling reach and opportunity for SMBs Ntegral Inc.’s President and CTO, Dexter Hardy, will be onstage at Ultimate Partner LIVE Reston . The session will explore practical ways SMBs can build on their Marketplace presence to support customer reach and revenue growth. Hardy will share Ntegral’s journey from a regional systems integrator to a software company focused on developing its own solutions and reaching customers globally through Marketplace. 💡Ntegral's point of view: Marketplace adoption in the age of AI Ntegral sees Marketplace as an important part of scaling its business, alongside a product strategy designed around the needs of SMB customers. Ntegral recently introduced Akili , its AI-powered platform designed for SMBs and consultants. Akili brings access to AI models and agent capabilities into one workspace, giving small teams and solo operators a way to use these capabilities without managing separate subscriptions. For Ntegral, that product strategy is closely connected to how the company approaches Microsoft Marketplace. Ntegral sees AI adoption and Marketplace as complementary parts of its growth strategy: developing products around the needs of small businesses while using Marketplace to reach customers and support transactions at scale. For Ntegral, Marketplace is part of a broader commercial strategy that connects product innovation with customer reach and scalable sales. At UP LIVE Reston, Dexter brings that same directness to the stage. The focus is on practical mechanics: how software companies can build on their Marketplace presence to reach more customers and develop more pipeline, how AI fits into that strategy, and what Ntegral changed operationally as its business evolved. Learn more about Akili . __________________________________________________________________________________________________________________________________________________________________ 📅 Attend UP LIVE Reston · October 26–28, 2026 Carahsoft Conference & Collaboration Center, Reston, VA 👉 Register for UP LIVE Reston 1 World Bank Group / IFC MSME Finance Factsheet 2 Ntegral | Empowering Digital and Cloud Transformations | Ntegral

Nginx package update for PHP apps on Azure App Service

Fri, 09 Oct 2026 00:00:00 +0000

We’re updating the Nginx packages used in Azure App Service PHP images, moving from the deprecated deb.sury.org repository to the official nginx.org repository. This follows the upstream repository changes.

[Launched] Generally Available: Managed StandardV2 NAT Gateway for AKS

Thu, 08 Oct 2026 22:51:01 +0000

AKS will now provision and manage a StandardV2 NAT Gateway for clusters using an AKS-managed virtual network.StandardV2 is now the default managed NAT Gateway SKU for new clusters in supported regions when using the managedNATGateway outbound type. Standa

Post-quantum authentication: Why organizations should start testing certificate ecosystems now

Thu, 08 Oct 2026 20:44:28 +0000

Prepare for post-quantum authentication by testing certificate ecosystems now. Learn how Microsoft’s PQC TLS Pilot Program helps advance future readiness. The post Post-quantum authentication: Why organizations should start testing certificate ecosystems now appeared first on Microsoft Security Blog .

Evaluating Voice Agents: How Reliable Are Foundry's Multi-turn Evaluators?

Thu, 08 Oct 2026 20:00:00 +0000

Teams developing voice agents need automated evaluation because human review alone cannot keep pace with thousands of calls and frequent agent updates. Microsoft Foundry addresses this need with multi-turn evaluators that assess agent behavior and outcomes across complete conversations. To understand how these evaluators behave on voice-agent traces, we evaluated Task Completion and Generated Rubric on benchmark conversations and traces from a Foundry voice agent. This article examines call-level accuracy, agent ranking, run-to-run agreement, and rubric-based scoring. Authors: Sheng Liu, Shivank Goel, Morteza Ziyadi The Evaluators Both task completion evaluator and rubric evaluator take a complete multi-turn conversation as input and use a judge model to automatically assess it. They differ in their evaluation criteria and outputs. Task Completion: evaluates whether the user's task was successfully and completely accomplished. It returns a binary success result (true or false) and an explanation of why the task was judged complete or incomplete. Generated Rubric: evaluates the conversation against criteria generated from user-provided evaluation requirements. It returns a weighted overall score from 0 to 1, a pass/fail result, and per-criterion scores with explanations. Study Design Task Completion Datasets. We evaluated task completion on two trace datasets: τ-Voice benchmark traces. This dataset contains 3000+ simulated calls across airline, retail, and telecom tasks, produced by 12 voice-agent configurations spanning audio-native and cascaded systems. Figure 1 focuses on the nine gpt-realtime, Gemini Live, and cascaded configurations included in this article. We only keep conversations where τ-Voice’s user simulator follows the instruction it receives. Foundry agent traces. This dataset contains calls generated by one Foundry voice agent backed by gpt-realtime-2 on τ-Voice tasks. We only keep conversations where τ-Voice’s user simulator follows the instruction it receives. Judges. We kept the Task Completion evaluator fixed and report results from seven GPT judge configurations. For each call, we compared the evaluator verdict with the reference pass/fail label in the study data. Agent ranking and run-to-run agreement were measured on the τ-Voice benchmark traces. Generated Rubric We evaluated Generated Rubric on telecom conversations produced by one Foundry voice agent backed by gpt-realtime-2 on τ-Voice tasks. gpt-5.4-mini generated the rubric from requirements describing the expected behavior. gpt-5.4 and gpt-5.6-sol each scored the same 114 conversations with Generated Rubric, and we compared their predictions with the reference pass/fail labels. Metrics Balanced accuracy is our primary correctness metric for both evaluators. For task completion, we also report raw accuracy, ranking agreement, and repeatability. Balanced accuracy. The average of success recall and failure recall: (success recall + failure recall) / 2. Each recall is the proportion of calls with that outcome labeled correctly. Equal weighting prevents the majority class from dominating the score. Raw accuracy. The percentage of calls whose verdict matches the reference label. Unlike balanced accuracy, it reflects the dataset's mix of successful and unsuccessful calls. Kendall's τ. Agreement between evaluator and benchmark agent rankings. It ranges from -1 for reverse order to 1 for identical order; 0 indicates no overall rank association. Higher values mean more consistent rankings. Pairwise order agreement. The percentage of agent pairs ordered identically by the evaluator and benchmark. The 12 agents form 66 pairs. We report agreement for all pairs and for clearly separated pairs whose benchmark pass rates differ by more than 10 percentage points. Repeatability. Consistency when four agents are graded twice under identical settings. We report the percentage of unchanged predictions, absolute changes in balanced accuracy and whether agent rankings are preserved. Higher agreement and smaller accuracy changes indicate more stable judgments. Task Completion Results Call-Level Accuracy In our Microsoft internal study, Task Completion produced approximately 83% balanced accuracy and 85% raw accuracy with gpt-5.6-terra as judge on the kept τ-Voice benchmark calls. Table 1 summarizes one reported value for each metric across the seven judges retained in this article. Metric Rounded study value Balanced accuracy 83% Raw accuracy 85% Kendall's τ 0.818 Pairwise agreement: all pairs 91% Pairwise agreement: gap > 10 pp 100% Prediction agreement 97% Table 1. Cross-judge metric summary for the seven GPT judge configurations retained from our Microsoft internal study. Percentage values are rounded to the nearest whole percent; Kendall's τ is shown to three decimals. Values in different rows can come from different judges and should not be read as the results of one configuration. The study did not test statistical significance. Figure 1 reports balanced accuracy for each displayed judge-agent combination in our Microsoft internal study. Its nine rows are the gpt-realtime, Gemini Live, and cascaded voice-agent configurations retained for this article; its seven columns are the retained GPT judge configurations. The matrix is descriptive, and the study did not test whether differences between judges were statistically significant or generalize beyond these traces. Figure 1. Descriptive balanced accuracy for 63 displayed judge-agent combinations from our Microsoft internal study. Agent Ranking Many evaluation decisions concern agent ordering, not just whether one call passed. In our Microsoft internal study, we ranked the 12 agents in the τ-Voice benchmark dataset by evaluator-derived pass rates and compared the ordering with the benchmark. Across the seven GPT judges retained in this article, Kendall's τ ranged from 0.758 to 0.818. Pairwise agreement included an observed value of 90.9% across all 66 agent pairs, with a mean of 89.8% across the seven judges. Judge Kendall's τ Pairwise agreement rates (%) Every pair Gap > 10 % gpt-5.4-mini 0.818 90.9 100.0 gpt-5.4-nano 0.818 90.9 100.0 gpt-5.6-luna 0.818 90.9 100.0 gpt-5.1 0.788 89.4 100.0 gpt-5.4 0.788 89.4 100.0 gpt-5.6-sol 0.788 89.4 100.0 gpt-5.6-terra 0.758 87.9 100.0 Table 2. Descriptive agent-ranking results for the seven GPT judges retained from our Microsoft internal study. “Every pair” covers all 66 pairs of 12 agents. “Gap > 10 pp” restricts the calculation to pairs whose benchmark pass rates differ by more than 10 percentage points. No significance analysis was conducted for differences among judges. For pairs whose benchmark pass rates differed by more than 10 percentage points, all seven retained judges ordered every pair in the same direction as the benchmark. More disagreements were observed among pairs with closer benchmark pass rates. These observations apply only to the tested agents, traces, judges, and ranking procedure. Results Across Judges With gpt-5.6-terra as judge, Task Completion produced 82.7% balanced accuracy across the τ-Voice benchmark traces. With gpt-5.6-luna, it produced 80.3%, an observed difference of 2.4 percentage points. The corresponding Kendall's τ values were 0.758 and 0.818, and pairwise agreement values were 87.9% and 90.9%. These descriptive measurements reflect different aspects of the tested configurations. The study did not evaluate pricing, latency, volume, or economic value, and it did not test whether the observed differences were statistically significant or equivalent; the values therefore do not establish a recommended default judge. Agent Judge Balanced accuracy (%) All agents gpt-5.6-terra 82.7 Additional measured result gpt-5.6-luna 80.3 gpt-realtime gpt-5.6-terra 82.0 Additional measured result gpt-5.4-mini 77.4 Cascaded gpt-5.6-terra 80.8 Table 3. Selected descriptive results for GPT judges by retained voice-agent group in our Microsoft internal study. Observed scores varied by retained voice-agent group in Table 3. With gpt-5.6-terra, the displayed values were 82.7% across all benchmark agents, 82.0% for gpt-realtime, 78.6% for Gemini Live, and 80.8% for the cascaded configuration. The additional measured values were 80.3% with gpt-5.6-luna across all agents and 77.4% with gpt-5.4-mini for gpt-realtime. These descriptive differences do not establish that one judge is generally superior or that agent architecture caused the observed values. Figure 1 provides the corresponding measurements for the nine displayed voice-agent configurations. Repeatability To measure run-to-run agreement in our Microsoft internal study, we graded the same four benchmark voice-agent configurations twice with each of the seven GPT judges retained in this article under unchanged settings. The subset contained exactly 1,109 calls per judge and included audio-native and cascaded configurations. We call an individual verdict that changes between the two runs a prediction flip, and a judge's flip rate is the percentage of calls with a flipped verdict. Across the seven judges, mean prediction agreement was 95.1%, mean absolute change in balanced accuracy was 0.8%, and the largest observed change was 2.4%. Judge Balanced acc., run 1 (%) Balanced acc., run 2 (%) Change (%) Prediction flips (%) Same agent ranking gpt-5.6-terra 82.4 80.9 1.5 6.0 yes gpt-5.6-sol 81.8 82.0 0.2 3.4 yes gpt-5.4 79.2 78.9 0.3 4.0 yes gpt-5.6-luna 78.9 79.9 1.0 4.2 yes gpt-5.4-mini 78.1 75.7 2.4 8.8 no gpt-5.1 77.8 77.6 0.2 4.1 yes gpt-5.4-nano 74.6 74.5 0.1 4.1 yes Table 4. Two runs under unchanged settings on the same set of calls. Changes in balanced accuracy are calculated from the displayed score. Prediction flips are the percentage of individual verdicts that changed. Six of the seven retained judges reproduced the same agent ranking. gpt-5.6-sol had a 3.4% flip rate and preserved the ranking; gpt-5.4-mini had a 2.4% accuracy change and an 8.8% flip rate and changed the ranking. These cases show why prediction agreement and ranking stability are reported as separate descriptive measures. They do not establish a general repeatability ordering among models. Foundry Agent Results We applied the same Task Completion evaluator and judge panel to the 278 Foundry agent traces described in Study Design. These calls were generated by one Foundry voice agent backed by gpt-realtime-2 on τ-Voice tasks and collected through Foundry's observability pipeline. Judge Balanced acc. (%) Raw accuracy (%) gpt-5.6-terra 80.7 80.2 gpt-5.6-luna 79.4 76.4 gpt-5.4 79.3 77.5 gpt-5.6-sol 78.2 77.8 gpt-5.4-nano 76.9 73.5 gpt-5.4-mini 76.7 76.3 gpt-5.1 76.6 74.7 Mean (7 listed judges) 78.3 76.6 Table 5. Descriptive Task Completion results for the seven GPT judges retained from our Microsoft internal study, measured on our kept τ-Voice task traces from one Foundry voice agent backed by gpt-realtime-2. The mean row averages the seven listed judges. No confidence intervals or significance tests were calculated. Across the seven retained judges, balanced accuracy on the 278 Foundry agent traces averaged 78.3% and ranged from 76.6% to 80.7%. With gpt-5.6-terra, the observed values were 80.7% balanced accuracy and 80.2% raw accuracy, compared with 82.0% balanced accuracy on the gpt-realtime subset of the τ-Voice benchmark traces. With gpt-5.6-luna, the corresponding balanced-accuracy values were 79.4% and 79.2%. These measurements describe the two tested datasets; without significance or equivalence testing, they do not establish matching performance or a recommended judge. Generated Rubric Results Task Completion applies a common definition of successful task resolution. Generated Rubric translates user-provided evaluation requirements into scoring criteria. We measured both evaluators on the same telecom conversations to describe their observed scores under the two tested judge configurations. Table 6 reports both evaluators on the same set of kept τ-Voice telecom conversations generated by one Foundry voice agent backed by gpt-realtime-2. gpt-5.4 and gpt-5.6-sol each applied both evaluators to the same calls. Judge Rubric bal. acc. (%) Task completion bal. acc. (%) Difference (%) gpt-5.4 74.5 76.8 −2.3 gpt-5.6-sol 78.5 76.3 +2.2 Table 6. Generated Rubric and built-in Task Completion on the same set of kept τ-Voice telecom conversations generated by one Foundry voice agent backed by gpt-realtime-2. gpt-5.4-mini generated the rubric. The difference is Generated Rubric balanced accuracy minus Task Completion balanced accuracy. In our Microsoft internal study, Generated Rubric produced 74.5% balanced accuracy and Task Completion produced 76.8% with gpt-5.4 as judge, a difference of −2.3%. With gpt-5.6-sol, the observed values were 78.5% and 76.3%, a difference of +2.2%. The study did not run significance or equivalence tests, so these differences do not establish that either evaluator is superior or that their accuracy is equivalent. Generated Rubric lets teams turn user-provided evaluation requirements into scoring criteria without writing a rubric from scratch. Those requirements can cover task outcomes, expected behavior, or other aspects of quality that matter to an application. On the tested telecom conversations, Table 6 reports the observed scores; this study does not establish equivalent accuracy to built-in Task Completion. Observed Results and Study Scope In this Microsoft internal study, Task Completion and Generated Rubric produced the descriptive measurements reported above for the specified τ-Voice benchmark calls, Foundry agent traces, retained GPT judge configurations, and evaluator settings. The findings do not establish general evaluator reliability, judge superiority, or equivalence between the two evaluators. They illustrate how call-level accuracy, agent ranking, run-to-run agreement, and rubric-specific criteria can be examined within a defined evaluation setup. Get Started To evaluate your own voice agent, open your project in Microsoft Foundry and select conversations that reflect the tasks and behaviors you want to assess. Follow the conversation evaluation guide to run task completion across complete conversations. To evaluate against your own requirements, use the rubric evaluator guide to generate a rubric and apply it to those conversations. Review the scores and explanations to understand where the agent meets your expectations and where it needs improvement. The voice-agent observability guide explains how to capture and inspect the conversation traces. The voice-agent observability and evaluation workflow discussed here is currently in Preview, is provided without a service-level agreement, and is not recommended for production workloads. Availability and interface paths may vary by region and release.

[Launched] Generally Available: Azure Database for PostgreSQL flexible server in East US 3

Thu, 08 Oct 2026 19:56:31 +0000

Now you can deploy Azure Database for PostgreSQL flexible server in the East US 3 Azure region. Learn more.

Dynamic Workflows in Azure Functions Hosted Skills: Durable, AI-Led Work for Event-Driven Apps

Thu, 08 Oct 2026 19:09:00 +0000

Azure Functions is the event-driven application platform, and Hosted Skills adds AI reasoning to your app. Dynamic Workflows give the app a durable way to carry out AI-led, multi-step work after the triggering invocation is finished. The model writes a plan (a DAG) one time, and Durable Functions runs it. In our benchmark, token use decreased by 56-93% and end-to-end latency decreased by 77-95%, with the same output quality. The post Dynamic Workflows in Azure Functions Hosted Skills: Durable, AI-Led Work for Event-Driven Apps appeared first on Azure SDK Blog .

Protecting Organizations from External Email Risks in Microsoft 365 Copilot

Thu, 08 Oct 2026 18:28:31 +0000

Introduction As organizations embrace Microsoft 365 Copilot (Copilot), a new category of risk emerges: what happens when Copilot grounds its responses in untrusted external emails? Messages from external or unverified senders can carry content Copilot shouldn’t rely on. A new policy in Microsoft Purview Data Loss Prevention (DLP) addresses exactly this challenge. It lets organizations ground Copilot in trusted internal email only—reducing the risk of cross-prompt injection, while keeping everyday work uninterrupted. Why This Matters: The Risk of External Email in Copilot Grounding Copilot is built to integrate deeply with your organizational data—emails, files, meetings, and more—to generate intelligent and context-aware responses. However, not all mailbox content is equally reliable. External emails—messages originating from outside your organization’s trusted domains—can introduce risks such as: Prompt injection (or cross prompt injection) attempts disguised as legitimate communication Manipulated or misleading content aimed at influencing Copilot-generated outputs Unverified information or instructions that may lead to inaccurate responses Social engineering content that could be amplified through Copilot summarization Without proper safeguards, Copilot may inadvertently reference or summarize this content, potentially impacting decision-making or exposing users to biased or manipulated information. Consider a common scenario: an employee receives a message from an outside address that looks like a routine vendor note but contains hidden text instructing any AI assistant to ignore prior guidance and surface the recipient’s recent internal updates. Later, the employee asks Copilot to "summarize my inbox." Without this policy, that external message is eligible for grounding, and its planted instructions could influence the summary. With this new policy enabled, the external email is excluded from grounding entirely—Copilot never reads it as a source, so the injected instructions have no effect. How It Works: Under the Hood The feature operates through a DLP policy configured in the Microsoft Purview portal using the "Microsoft 365 Copilot and Copilot Chat" policy location with the "Email is received from > External users" condition. Here is how Copilot enforces the policy at runtime: Metadata Evaluation: Copilot evaluates email metadata and it checks the sender’s domain against your tenant’s accepted domains to determine whether an email is internal or external. Importantly, the body of the email is not inspected—only sender metadata is evaluated. External Emails Excluded from Grounding: Emails received from an external sender are excluded from Copilot grounding (source) data. This means when a user asks Copilot to summarize their inbox or reason over recent communications, those external emails are not referenced, summarized, or cited in the response. Other Grounding Sources Remain Available: Results from other grounding sources, such as web search, Word documents, Excel files, PowerPoint presentations, and internal emails, continue to show up in Copilot responses as normal. The policy is surgical in scope. No Impact on Email Access: User access to email remains completely unchanged. Users can still read, reply to, forward, and manage all their external emails as they always have. No Impact on Mail Flow: The policy does not affect mail flow, delivery, or retention. It operates exclusively at the Copilot grounding layer, not at the transport or storage layer. Things to Keep in Mind A few points help set the right expectations before you deploy: Metadata-only evaluation: The policy evaluates sender metadata, not message content. It does not scan or analyze the body of any email. Scoped to the grounding layer: The policy affects only what Copilot can use as a grounding source. It does not change mail flow, delivery, retention, or a user’s ability to access their email. Other sources are unaffected: Internal emails, files, and web results remain available to Copilot, so most everyday scenarios are unchanged. Validate before enforcing: Assess where external email is important to business workflows, then use simulation mode to validate impact and apply the protection only where it is relevant and needed. Key Benefits for Your Organization Mitigates Cross-Prompt Injection Risk: By excluding untrusted external email from Copilot’s grounding data, organizations significantly reduce the attack surface for prompt injection attempts embedded in incoming email. Applies protection where it is needed: Organizations can use the policy when external email presents a meaningful risk to Copilot grounding, while leaving external email available in scenarios where it is relevant and trusted. Ensures Copilot Responses Are Grounded in Trusted Data: Copilot responses reflect only your organization’s internal, verified communications, building greater confidence in Copilot generated insights. Minimal Disruption to Productivity: The feature keeps everyday work uninterrupted. Users retain full access to all their emails, and Copilot continues to function using all other permitted data sources. Simple Policy-Based Administration: Configured through familiar Microsoft Purview DLP policy workflows, making it easy for compliance and security teams to deploy and manage. Transparent User Experience: Users receive clear notifications when organizational policies restrict content, maintaining trust and transparency in the Copilot experience. Prerequisites Before you begin, make sure you have: Permissions: An account with the Compliance Administrator or Data Loss Prevention administrator role, or equivalent permissions to create DLP policies in the Microsoft Purview portal. Accepted domains: Your tenant’s accepted (internal) domains configured correctly, since these determine which senders are treated as internal versus external. How to Set It Up Setting up this protection is straightforward: Sign in to the Microsoft Purview portal (https://purview.microsoft.com). Navigate to Data Loss Prevention > Policies and select + Create policy. Choose the Custom template, then Custom policy. On the Locations page, enable the Microsoft 365 Copilot and Copilot Chat location. Add a rule with the condition "Email is received from," and set the value to External users. Set the action to "Prevent Copilot from processing content". Deploy the policy in simulation (test) mode first, and review the impact to confirm only the intended external email is affected. Once validated, save and activate (enforce) the policy. Conclusion As M365 Copilot becomes central to enterprise productivity, organizations must control what data feeds its responses. This new policy features adds a critical layer of defense, grounding M365 Copilot in trusted internal data while keeping the door open to seamless collaboration. By deploying this DLP policy, you protect more than data—you protect the integrity and trustworthiness of every Copilot-generated insight your organization relies on. Ready to get started? Create the policy in simulation mode today, validate the impact, and enforce it once you’re confident—so every Copilot response your organization relies on is grounded in data you trust. Learn more: https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-learn-about

Why DLP for External Web Search in Microsoft 365 Copilot Matters?

Thu, 08 Oct 2026 18:28:13 +0000

Introduction Microsoft 365 Copilot (Copilot) grounds its responses in your organizational data—emails, files, chats—and, optionally, the public web. With web search enabled, Copilot fetches real-time information from the Bing search service to deliver richer, more current answers. But what happens when a user’s prompt contains sensitive data such as credit card numbers, passport numbers, or Social Security numbers? That’s where a new feature in Microsoft Purview Data Loss Prevention (DLP) becomes essential: it keeps sensitive information from reaching external web search during Copilot’s query generation, preventing inadvertent data leakage while preserving the productivity benefits of AI. At a Glance In short: admin and user toggles decide whether Copilot can search the web; Microsoft Purview DLP decides what data may leave when it does. . Admin and user toggles are binary on/off controls—they aren’t aware of sensitive data. Prevents Copilot from using external web search as a grounding source for that prompt. It does not block the prompt itself or prevent Copilot from generating a response using permitted sources. It works regardless of your web search configuration,even as a safety net if web search is disabled. The Web Search Landscape in Copilot Before diving into the DLP feature, it’s important to understand the web search controls already available in Copilot and how they interact with this DLP feature. How Web Search Works in Copilot When web search is enabled, Copilot parses user prompts and generates search queries sent to the Bing search service. These generated queries are different from the user’s original prompt—they consist of a few words informed by the prompt. Importantly: The user’s entire prompt is NOT sent to Bing (unless it’s very short) Entire Microsoft 365 files (emails, documents) are NOT included in the search query User and tenant identifiers are removed before queries reach Bing Web search queries are not used to improve Bing, create advertising profiles, or train AI models Queries are treated as customer confidential information Admin Controls for Web Search IT administrators have several options to manage web search through the "Allow web search in Copilot" policy in Cloud Policy service for Microsoft 365: Enabled in Microsoft 365 Copilot and Microsoft 365 Copilot Chat: Web search is available across all Copilot experiences. Users get the Web content toggle to control it personally. Disabled in Microsoft 365 Copilot and Microsoft 365 Copilot Chat: Web search is completely turned off. The Web content toggle is dimmed and unavailable to users. Disabled in Work mode; Enabled in Web mode and Copilot Chat: A hybrid approach where web search is blocked in Work mode (where organizational data is accessed) but available in Web mode and Copilot Chat. User-Level Control: The Web Content Toggle When the admin enables web search, users in Copilot (Work chat) have a "Web content" toggle that is ON by default. Users can turn it off to exclude web content from their Copilot responses. This toggle is NOT available in Copilot Chat. The Gap: Why Admin Controls and User Toggles Are Not Enough Here’s the critical question: What if your organization has web search enabled (for good reasons—better answers, real-time data, improved productivity) but a user inadvertently includes sensitive information in their prompt? Consider these scenarios: A user asks Copilot: "What are the compliance requirements for processing credit card number 4532-XXXX-XXXX-1234?" An employee types: "Find regulations related to passport number AB1234567 for our international transfer." A prompt includes a customer’s Social Security number while asking about tax filing procedures. In each case, if web search is enabled, Copilot might generate a search query informed by the sensitive data in the prompt. Even though Copilot doesn’t send the entire prompt to Bing, the generated search query could still be influenced by or contain fragments of sensitive information. This is the gap that DLP for external web search fills—and it works regardless of which web search configuration option your admin has chosen. The Solution: DLP Policy to Restrict Web Search When Prompts Contain Sensitive Data Microsoft Purview DLP allows you to create a policy that detects when a user’s prompt contains sensitive information types (SITs)—such as credit card numbers, passport numbers, Social Security numbers, or custom SITs defined by your organization—and automatically prevents Copilot from using external web search as a grounding source for that specific prompt. How It Works Real-Time Detection: The DLP policy evaluates each prompt in real time, checking for configured sensitive information types before Copilot generates any web search query. Surgical Blocking: Only the web search component is prevented for that specific prompt. Copilot continues to generate responses using permitted internal Microsoft 365 data sources (emails, files, chats) where applicable. Per-Prompt Enforcement: The restriction applies only to prompts that actually contain sensitive data. The next prompt from the same user (without sensitive data) will use web search normally. Supports various available SIT Types: Works with Microsoft-provided SITs (credit cards, passports, SSNs, etc.) and custom SITs defined by your organization. Clear User Notification: Users are informed that web search was restricted for their prompt due to organizational policy, maintaining transparency. Why This Feature Is Critical, Regardless of Your Web Search Configuration This is the key insight that every security and compliance team must understand: The DLP policy for external web search provides a fundamentally different layer of protection than the admin toggle or user toggle for web search. Scenario 1: Web Search Fully Enabled With web search enabled across all Copilot experiences—the most common setup—the DLP policy acts as a safety net. Normal prompts get full web-grounded answers, but the moment a prompt contains sensitive data, web search is blocked for that prompt alone. External web grounding is prevented for that prompt when the policy detects configured sensitive content. Scenario 2: Web Search Disabled in Work Mode, Enabled in Web Mode Even here, users in Web mode and Copilot Chat still have web search active. The mode-level toggle is binary (on/off) and can’t tell safe prompts from sensitive ones—so if a prompt in these modes contains sensitive data, DLP adds prompt-level, data-aware protection beyond binary web-search controls.. Scenario 3: Web Search Enabled with User Toggle Available Expecting users to toggle off web search before every sensitive prompt is unrealistic—they don’t always know when content counts as sensitive by compliance standards. The DLP policy removes that human error, detecting and blocking automatically on a per-prompt basis. Scenario 4: Even When Web Search Is Fully Disabled Even with web search disabled entirely, the DLP policy adds defense-in-depth. Configurations change, policies get modified, and new users join groups with different settings. If web search is ever re-enabled—intentionally or not—the policy keeps sensitive data protected. Comparing the Controls: A Side-by-Side View Control Scope Granularity Sensitive Data Aware? Admin Policy (Allow web search) Tenant/User Group Binary: On or Off per mode No User Web Content Toggle Individual User Binary: On or Off No DLP: Block Web Search for SITs (Recommended) Per Prompt (Real-Time) Layered defense-in-depth; Conditional Block: Only when SITs detected Yes Key Takeaway: The admin toggle and user toggle control whether web search is available. The DLP policy controls what data can be sent when web search is available. These are complementary, not overlapping controls. Prerequisites Before you configure the policy, make sure you have: Licensing: Microsoft 365 Copilot licenses for your users, plus Microsoft Purview Data Loss Prevention (included with Microsoft 365 E5 or E5 Compliance, or an equivalent plan). Permissions: An account with a role that can create DLP policies for the Copilot location, e.g. Compliance Administrator or the Purview Data Security AI Admin role. Sensitive information types: The Microsoft-provided or custom SITs you want to detect (credit card numbers, passport numbers, SSNs, and so on) identified ahead of time. How to Configure the DLP Policy Follow these steps to set up the protection in Microsoft Purview: Sign in to the Microsoft Purview portal (https://purview.microsoft.com). Go to Data Loss Prevention > Policies and select + Create policy. Select the Custom template, then Custom policy. On the Locations page, set the Microsoft 365 Copilot and Copilot Chat location to On. Add a rule with the "Content contains" > "Sensitive information types" condition and choose the SITs you want to detect (e.g., Credit Card Number, Passport Number, SSN, or custom SITs). In the same rule, set the action to "Prevent Copilot from processing content" > "Performing Web Searches". Save and turn on the policy. Policy Design note : Conditions based on sensitive information types and sensitivity labels must be configured in separate rules within the same policy. Note: DLP policy changes can take up to 4-8 hours to take effect in Copilot. Deploy in simulation (test) mode first to review the impact before you enforce the policy. Real-World Use Case: Contoso Contoso wants employees to use Copilot for productivity and has web search enabled to provide the best possible responses. However, they don’t want sensitive customer data—such as credit card numbers or national identification numbers—to be sent to external web search when Copilot grounds responses on the web. They configure a DLP policy targeting the Microsoft 365 Copilot and Copilot Chat location with a rule that detects their relevant SITs and sets the action to "Prevent Copilot from processing content" > "Performing Web Searches". Result: When a user submits a prompt containing those SITs, Copilot does not send the prompt to external web search. Copilot still returns a response grounded in internal Microsoft 365 data sources where the user has access. For all other prompts, web search works normally. Other prompts can continue to use web search, subject to applicable settings and policies Best Practices Deploy the DLP web search policy alongside your existing web search admin controls for defense-in-depth. Include both Microsoft-provided and custom SITs relevant to your industry and data classification. Use simulation mode first to understand the impact before enforcing the policy. Combine with the "Prevent sensitive information types in prompts" DLP action for comprehensive protection (note: these must be separate rules within the same policy). Regularly review DLP alerts to identify patterns of sensitive data in prompts that may indicate user training needs. Document your layered approach: admin toggle for broad control, DLP for data-aware conditional control. Conclusion The “Restrict Microsoft 365 Copilot from using external web search when prompts contain sensitive data” DLP capability fills a critical gap. Admin policies and user toggles give broad on/off control over web search availability, but they can’t tell a prompt that’s safe to ground on the web from one carrying sensitive information that must never leave your Microsoft 365 boundary. This DLP feature adds intelligent, real-time, per-prompt protection that works regardless of your web search configuration. Users keep the productivity benefits of web-grounded Copilot responses without compromising data security—a clear example of security enabling productivity rather than restricting it. Bottom line: If your organization uses M365 Copilot with web search in any capacity, this DLP policy isn’t optional—it’s essential. References DLP for Microsoft 365 Copilot, Copilot Chat and Cowork: https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-learn-about Data, Privacy, and Security for Web Search in Copilot: https://learn.microsoft.com/en-us/microsoft-365/copilot/manage-public-web-access

Retirement: Microsoft Dev Box will be retired on September 18, 2028

Thu, 08 Oct 2026 18:23:25 +0000

Microsoft Dev Box will retire on September 18, 2028. Beginning on September 14, 2026, Microsoft Dev Box will begin the closing-down process. After retirement, Microsoft Dev Box will no longer be available. Microsoft Dev Box is currently in maintenance mod

Power BI September 2026 Feature Summary

Thu, 08 Oct 2026 18:20:42 +0000

As the Power BI, Microsoft Fabric, data, and analytics community gathers in Barcelona for the European Microsoft Fabric + SQL Community Conference, this month is packed with news. From new Copilot and AI experiences to reporting, modeling, data connectivity, developer enhancements, and mobile updates, we're sharing the latest innovations designed to help you build, analyze, and act on your data more effectively. Whether you're joining us in person or following along from afar, this roundup is your guide to everything new across Power BI this month. Table of Contents General Deprecation of Old File Picker experience in Power BI Desktop Copilot and AI Power BI Agentic Experiences (Generally Available) Microsoft 365 Copilot is coming to Power BI (Preview) Power BI data answers in Microsoft Copilot Chat (Generally Available) Fabric IQ Plugin in Microsoft 365 Copilot Cowork (Generally Available) Build Fabric Apps more easily in GitHub Copilot App (Preview) Enhanced Report Consumption Copilot with Fabric IQ New control for Copilot access to semantic models Remote Power BI Authoring MCP Server (Preview) Reporting New Report Ribbon on the web (Preview) Live Visual Sharing in Outlook on the web (Preview) More control and context in Power BI Home (Generally Available) Set and reset column widths in table and matrix (Generally Available) Visual calculations for small multiples (Generally Available) Design ribbon for Power BI reports (Generally Available) Slider color options for Slicer visual (Generally Available) Translytical task flows show user date function (UDF) information in button action (Generally Available) Format pane headers stay visible as you scroll (Generally Available) Pick the axis initial scroll position (Generally Available) Azure Maps geocoding improvements (Generally Available) On-object interaction improvements (Preview) Support for Fabric Apps in Org apps (Coming Soon) Changes to Power BI subscription email delivery Increased Export to Excel row limits (Generally Available) Value selection in Narrative visual Modeling Create and edit DirectQuery semantic models in the Power BI service Approximate Distinct Count comes to Import and Direct Lake (Preview) Accelerate text searches in your semantic models with String Indexing (Preview) Introducing Full-Text Search in Power BI Semantic Models (Preview) Data connectivity New Power Query editor (Preview) Microsoft Outlook Mail connector (Preview) More flexible Data Privacy Firewall query patterns in Power BI Desktop (Preview) Mobile Mobile page indicator (Generally Available) Contact details in Info drawer (Generally Available) Developers and APIs Power BI Projects (PBIP) (Generally Available) New Purge Data option for Fabric APIs Other Data updated and sensitivity fields of Power BI report in Microsoft Teams preview card (Coming Soon) Artifact info header for Power BI tabs in Microsoft Teams (Generally Available) Third-party custom visuals graphomate matrix Drill Down Bubble PRO by ZoomCharts Commenting in view mode: introducing Zebra BI Tables+ & Charts+ Network Graph by Powerviz Hierarchical Bar Chart That’s a wrap! General Deprecation of Old File Picker experience in Power BI Desktop In April we deprecated the old file picker experience in Power BI Desktop. Starting in October, users using versions of Power BI Desktop from March 2026 or earlier will no longer be able to save and share Power BI files to OneDrive and SharePoint. Please ensure you update Power BI Desktop to keep using this functionality. Copilot and AI Power BI Agentic Experiences (Generally Available) Agentic development in Power BI is real, and it is already delivering value: whether you are starting from scratch with greenfield projects or building upon existing solutions in brownfield scenarios, BI developers can delegate the work to an agent, review the result, and refine it rather than starting from scratch every time. What makes this work is tools and context. Through Work IQ and Fabric IQ , the agent grounds its work in your business context—your data, your semantics, and the way your organization operates. Through skills —published by Microsoft in skills-for-fabric , shared by the community, or personalized by your own team—it also picks up your development context: the modeling and reporting practices, conventions, and workflows your team expects. Through tools such as the Power BI Authoring MCP server and the Power BI Desktop Bridge CLI, the agent can act on that context: reading and changing semantic models and reports directly, reloading its edits in Power BI tools, and reviewing its own work. Point an agent at a requirements document or a screenshot of the layout you want, describe what you need, and the agent can help accelerate the initial authoring pass, which you can then review and refine. Figure: Animated GIF showing the creation of a Power BI report based on a remote semantic model using Modeling MCP, the Modeling skill, and report authoring skills. What's a vailable today The powerbi -authoring plugin in microsoft /skills-for-fabric bundling the semantic modeling and reporting agent skills and tools. It was recently updated to support report authoring for remote semantic models in Power BI service and an expanded range of supported report visuals, including custom visuals. To learn more, refer to the Power BI skills documentation. The local Power BI Authoring MCP server allows the agent to edit semantic models in Power BI Desktop. To learn more, refer to the Power BI Authoring MCP documentation. Power BI Desktop Bridge lets an agent reload changes in a running instance of Power BI Desktop and capture screenshots to check its own work. To learn more, refer to the Power BI Desktop Bridge documentation. Browser-based validation for remote report editing , so the agent can validate a report using a headless browser (an automated browser that runs without a visible user interface). Removing the local Power BI Desktop dependency allows the full authoring loop to run without Power BI Desktop, extending the agentic experience to Mac users and others who do not rely on a local installation. To learn more and get started, refer to the Power BI agentic documentation. Microsoft 365 Copilot is coming to Power BI (Preview) Copilot experiences have emerged across the applications people use every day, bringing AI closer to the work happening in each product. But this can also feel fragmented, with different entry points, separate conversations, and uncertainty about which Copilot agent to use. Our goal is to create a consistent Copilot experience that is available wherever people work. People should not have to leave the application they are using to find it. Microsoft 365 Copilot should be available within their experience, carry relevant context across experiences, and connect to the specialized intelligence of each product. We’re taking an important step toward that goal with a preview of Microsoft 365 Copilot integrated directly into Power BI and Microsoft Fabric. This integration gives users a familiar place to bring together business context and trusted data. Shared conversation history lets them continue a discussion as they move between Microsoft 365 Copilot experiences instead of starting over in each application. Figure:Screenshot of Copilot Chat integrated into the Power BI experience, including integration with Work IQ. In Power BI, a question no longer has to stop with the numbers in a report. A sales leader could use Fabric IQ to identify which regions are behind plan, then use Work IQ to connect the results with customer emails, meetings, account plans, and documents. They could summarize the complete picture and even kick off actions and tasks in Cowork, all from inside Power BI. This work context and ability to move directly from insight to action were not available in the standalone Power BI Copilot experience. Figure:Screenshot of the Cowork integration into the Power BI experience , highlighting the full M icrosoft 365 experience embedded into Power BI. A new setting in the Fabric admin portal will determine whether this integration is available by enabling or disabling its entry point in the navigation pane. It will be off by default, giving administrators time to evaluate the experience before introducing it to their organization. Administrators can enable it when they are ready and disable it if they need to pause access. This setting is independent of the existing setting for standalone Power BI Copilot. If both settings are enabled, users with a Microsoft 365 Copilot license will see entry points for both experiences, and standalone Power BI Copilot will continue to appear on Home. If standalone Power BI Copilot is disabled and Microsoft 365 Copilot is enabled, users will see only the Microsoft 365 Copilot entry point. During the initial preview, the integrated experience is available only to users with a Microsoft 365 Copilot license. These users receive the full Copilot Chat experience in Power BI and Fabric, bringing together Fabric data through Fabric IQ and relevant Microsoft 365 context through Work IQ. Existing permissions and governance controls continue to determine which content each user can access. Support for a broader Fabric audience will follow. This expansion will give Fabric users without a Microsoft 365 Copilot license access to an integrated Copilot experience tailored to their available capabilities. The experience may differ from the full licensed offering, but it will extend Fabric IQ and conversational data experiences to more types of Fabric users. The preview will roll out with the setting turned off by default, with administrators choosing when to enable it for their organization. This is an important step toward one Copilot that meets people wherever they work, connecting the context surrounding each decision with trusted business data. To learn more, refer to the Copilot in Power BI documentation. Power BI data answers in M icrosoft Copilot Chat (Generally Available) Users can find and ask questions about Power BI reports and semantic models directly from Microsoft 365 Copilot. They can search for relevant Power BI content, attach a report or provide a link, and ask questions in natural language. Figure: Microsoft Copilot Chat featuring a data answer coming from a Power BI report, cited. Powered by Fabric IQ, the experience uses the data, measures, relationships, and business logic already defined in Power BI to provide grounded answers. Users can also bring Power BI insights into conversations that include their Microsoft 365 work context, such as emails, meetings, and documents. Microsoft 365 Copilot now supports Microsoft Purview Data Loss Prevention (DLP) policies and information protection controls for this experience. This helps organizations adopt conversational analytics while applying their existing policies for identifying, classifying, and protecting sensitive data. The experience continues to respect existing Power BI permissions and Microsoft 365 governance controls. Users can only access Power BI content they are authorized to view, and administrators retain control over whether Fabric data is available in Microsoft 365 Copilot. Organizations can use Power BI data answering in Microsoft 365 Copilot with production support and service commitments. This milestone makes it easier for users to bring trusted business data into the flow of work without leaving Microsoft 365 Copilot or creating a separate agent. To learn more, refer to the Fabric IQ in Microsoft 365 Copilot Chat (Frontier) documentation. Fabric IQ Plugin in Microsoft 365 Copilot Cowork ( Generally Available ) Power BI data is available where multi-step work happens, so a business question, the analysis behind it, and the follow-up it triggers stay in one place. To ground a task in Power BI, users can search for relevant content, attach a report, or paste a link to a report or semantic model. Questions are answered using the data, measures, relationships, and business logic already defined in the semantic model. Coverage now extends to reports published through organizational apps, with improvements to content discovery, large model handling, schema selection, Verified Answers, and row-level value search. The plugin also carries forward the governance controls organizations rely on in Power BI: Existing access controls : Power BI permissions and row-level security determine which reports and semantic models each user can reach. Citations and sensitivity labels : Responses cite the Power BI content behind an answer and surface the Microsoft Purview Information Protection label applied to it, so users can see where a number came from and how it is classified. From insight to actio n: With Fabric IQ, users can analyze Power BI reports using natural language, uncover key findings, and put those findings to work right away in Cowork. Whether they are summarizing business performance, investigating a trend, or answering a data question, Fabric IQ turns trusted organizational data into outcomes. To learn more about supported scenarios, setup, and current considerations, refer to the Fabric IQ in Microsoft 365 Copilot Cowork documentation. For licensing and pricing information, refer to Microsoft 365 Copilot plans and pricing . Build Fabric Apps more easily in GitHub Copilot App (Preview ) Fabric Apps were introduced in June as an AI-first way to build custom web apps with Microsoft Fabric as the backend. This month we’re excited to share that building these Fabric Apps on your governed data has become even easier with the GitHub Copilot App, which gives you a natural language chat interface instead of a command-line interface. Figure: GitHub Copilot App chat interface . To try it out, start by downloading the GitHub Copilot App . Then navigate to Customize > Plugins > Rayfin , and select Install to enable our dedicated plugin: Figure: Installing Rayfin plugin in GitHub Copilot App . Once the plugin is enabled, simply start a new chat and work with Copilot to help plan your Fabric data app. After you review and approve the plan, ask the agent to execute it and specify the workspace where you want to deploy the app. Figure: Example New York Taxi app . We look forward to seeing the amazing apps you build! Check out our community gallery for inspiration. Enhanced Report Consumption Copilot with Fabric IQ When viewing a Power BI report, you can enable Fabric IQ from the Copilot pane to better answer complex questions about your data. This enhancement merges existing Fabric IQ capabilities into Power BI Copilot report viewing mode, allowing Copilot to use a multi-step approach to evaluate data in the semantic model and refine its approach when generating a response. Figure: Fabric IQ enabled in Power BI Copilot report pane (viewing mode) to answer a data question with a supporting textual answer and visualization . With Fabric IQ enabled, Copilot can: Provide better answers to questions about your data based on detailed reasoning capabilities directly into the report viewing experience. Show reasoning steps to help you understand how Copilot provided an answer. Generate Fabric visuals to help you further analyze your data. Answers can include column, bar, stacked, line, area, pie, donut, scatter visuals. Provide the underlying DAX query and data table used to generate a response. Figure: GIF illustrating how to enable Fabric IQ in Power BI Copilot report pane (viewing mode) to answer data questions . To learn more, refer to the Ask Copilot questions about your data documentation. New c ontrol for Copilot a ccess to semantic models Power BI now provides semantic model editors with greater control over how Copilot can be used with their data. Users with write permissions can block read-only users from accessing a semantic model through Copilot and Microsoft’s remote MCP tools, supporting governance, compliance, and access-control requirements. The setting applies across Copilot experiences that query the semantic model, including Power BI Copilot experiences; Microsoft 365 Copilot Chat and Cowork; and data agents, remote Fabric MCP servers, and Power BI MCP servers. When disabled, users with read-only access won't be able to access that semantic model through these experiences. By default, the setting remains enabled to preserve the current behavior. This setting appears in the Copilot section with the following description: “Allow any person with read-only access to use AI (i.e. Copilot, Microsoft’s MCP tools) on the model and its related reports.” Figure: Setting that allows people with read-only permission to use AI experiences with the semantic model and its related reports. This update gives organizations a clear and enforceable way to control AI access to semantic model data while maintaining flexibility for semantic model editors. To learn more, refer to the Use Copilot with Semantic Models in Power BI documentation. Remote Power BI Authoring MCP Server (Preview) The Power BI Authoring MCP enables AI applications to create and modify semantic models in Fabric workspaces, without installing or maintaining anything local. This release also unblocks Mac users that want to use the Power BI Authoring MCP, because the server runs remotely and does not require local binaries. Use the following endpoint in AI applications such as GitHub Copilot App : https://api.fabric.microsoft.com/v1/mcp/powerbi/authoring Figure: Power BI Remote MCP Server configuration in GitHub Copilot App. The local Power BI Authoring MCP server , released in November 2025, remains generally available. It remains an option when an agent needs to work with Power BI Desktop, Power BI Project (PBIP) or TMDL files on disk. The local and remote servers support the same authoring capabilities. We recommend using the remote server when local development is not required, such as when creating a Direct Lake semantic model in a Fabric workspace. In the following example, the AI agent uses one tool call to create a Direct Lake semantic model connected to a Fabric Lakehouse: Figure: Using Power BI Remote MCP to create a Direct Lake semantic model. To learn more, refer to the Power BI Authoring MCP server documentation. Reporting New Report Ribbon on the web (Preview) The Report ribbon is now available on the web, providing a consistent experience for report consumption and authoring that more closely matches Power BI Desktop. The ribbon organizes commands into clear, easy-to-navigate tabs, making it easier for users to discover features, interact with reports, and complete editing and authoring tasks directly in the browser. It also introduces the new Design ribbon and additional capabilities that were previously unavailable on the web, such as Format Painter. This milestone brings greater consistency to Power BI report-authoring experiences and marks an important step toward a seamless, end-to-end reporting workflow on the web. As web authoring capabilities continue to expand, users will be able to accomplish more of their reporting tasks directly in the browser, enabling a more streamlined, productive workflow. Figure: New report ribbon on the web. Enable the Try the new ribbon (preview) at the top of the page to explore the new experience. You can disable the setting to return to the previous ribbon. To learn more, refer to the Report Ribbon on the web documentation . Live Visual Sharing in Outlook on the web (Preview) For years, sharing data through email has been stagnant. You could send a screenshot, but it immediately became stale. You could attach a report link, but recipients had to leave their workflow to find the context they needed. And every follow-up question often meant another screenshot, another export, or another email thread. Now, we're bringing a new way to share Power BI insights directly in the flow of work with Live Visual Sharing in Outlook. With Live Visual Sharing, you can insert a Power BI visual into Outlook on the web and share it as a live, interactive experience. Recipients can view and interact with the visual directly in Outlook while staying connected to the latest underlying data. Figure: A live Power BI visual in Outlook on the web. When a live visual is shared, Outlook renders an interactive version of the Power BI visual. Rather than embedding a static image, the experience remains connected to the source report and retrieves current data when viewed. Recipients can: Interact with the visual directly in Outlook on the web. Access tooltips and explore data points. See filters and slicers applied at the time of sharing. View refresh information and data context. Navigate back to the source report when deeper analysis is needed. The result is a richer conversation around data, directly within Outlook. Sharing a live visual is simple: Open a Power BI report in the service. Select a visual to share, then select More options in the upper-right corner. Select Share . Figure: Share option in Power BI. Select Link to this visual . Figure: Link to this visual as part of the share dialog. A pop-up will appear asking if you want to use the current view (apply existing filters and slicers) or not. After selecting Create Link , the link is copied to your clipboard. Figure: Before copying the link, you can configure the view in this dialog. Open Outlook on the web. This experience is not available in the Outlook desktop app. Create a new email. Paste the link in the email. The visual renders in loop after a few seconds! You can also share the same link in a Loop page, and the visual will also be rendered. Figure: An unfurled Power BI visual in Outlook on the web. By combining Power BI, Outlook, and Loop-powered experiences, we're bringing data closer to where collaboration happens. Live Visual Sharing can support more informed, data-driven conversations in Outlook. To learn more about Live Visual Sharing in Outlook, refer to the Share live Power BI visuals documentation. More c ontrol and c ontext in Power BI Home (Generally Available) Power BI Home now provides additional context and personalization options to help users discover the right content more efficiently. With new freshness indicators and customizable list views, you can quickly identify the most relevant reports and semantic models, prioritize the metadata that matters most, and tailor the experience to fit your workflow. Find the right content more easily Discover the right content more easily with new Data Refreshed and Modified Date columns in Power BI Home. By bringing the freshness signals already familiar from workspace list views into Home, users can more easily spot recently updated reports and semantic models, distinguish between similar items, and quickly find the content that matters most. Whether you're checking for the latest business updates or deciding which refreshed report to open, you can navigate with greater confidence and less guesswork. Figure: Power BI Home showing two new columns for Data refreshed and Modified date. Customize your Home l ist view Not every user, team, or organization relies on the same signals to discover content. With Column Options , you can show or hide metadata, drag and reorder columns to prioritize the information you use most, and reset to the default view at any time. Whether you rely on freshness signals, endorsements, sensitivity labels, or location information, you can tailor Home to match your workflow. Figure: Power BI Home showing new column options dropdown. To learn more, refer to the Power BI Home documentation. Set and reset column widths in table and matrix ( Generally Available ) You can now right-click a column header in a table or matrix and select Set column width to specify its width in pixels. This option helps report viewers improve readability and fit the information they need within the available space, without changing the report author’s design or affecting other viewers. Changes made by viewers last only for the current viewing session. To restore the width defined by the report author, right-click the column header and select Reset column width . Figure: Set or reset the width of an individual table or matrix column from its context menu. To learn more, refer to the Adjust column width in Power BI tables documentation. Visual calculations for small multiples ( Generally Available ) You can now use visual calculations in visuals with small multiples. Create calculations such as moving averages and compare trends across categories without adding separate measures to the semantic model. In the visual matrix, the field in the small multiples field well appears on the ROWPAGES axis. You can select ROWPAGES by itself or combine them with ROWS and COLUMNS to control how the calculation moves through the visual. Figur e: Create a moving average visual calculation for a line chart divided into small multiples by country. To learn more, refer to the Visual calculations overview documentation. Design ribbon for Power BI reports ( Generally Available ) The new Design ribbon brings report styling tools together in one location. Apply a built-in or organizational theme, open the Theme pane to customize report-wide defaults, or import and download theme files directly from the ribbon. You can also quickly open Page size , Page background , and Wallpaper settings for the current page. Figure: The Design ribbon provides theme controls and shortcuts to page formatting settings in Power BI Desktop. Two new built-in themes, Dark and Soft dark , use the new Versa color palette and styling that closely follows the Fluent 2 base theme. These themes let you design against a dark report canvas and return to the default light theme before publishing if needed. Figure: Apply the Dark built-in theme from the Themes gallery on the Design ribbon. To learn more, refer to the Use the Design ribbon in Power BI documentation. Slider color options for Slicer visual ( Generally Available ) Match your slicer's slider to your report design. The Slicer visual's Between , Before , After , and Date picker settings include a Slider format section where you can turn the slider on or off, set the handle style, and choose colors for the handles, selected range, and track. Handle options adjust based on the Responsive layout toggle ( General > Properties > Advanced options ). When Responsive is on, handles appear as circles with Fill color , Border , and Size . Figure: Slider formatting options for a date range slicer with Responsive layout turned on. When Responsive is off, handles appear as rectangular bars with Border , Width , and Height . Figure: Slider formatting options for a date range slicer with Responsive layout turned off. To learn more, refer to the Slicer visual in Power BI documentation. Translytical task flows show user date function (UDF) information in button action ( Generally Available ) The formatting pane now displays the Workspace , Function set , and Data function assigned to a data function button. These read-only details help you confirm that the button references the intended function without reopening the OneLake catalog. This information is especially useful when you review or troubleshoot reports that use several functions or connect to functions across multiple workspaces. Figure: View the workspace, function set, and data function assigned to a button in the formatting pane. To learn how to configure data function buttons, refer to Create a data function button in Power BI . Format pane headers stay visible as you scroll ( Generally Available ) Expanded section headers now remain visible at the top of the Format visual pane as you scroll through their settings. This update helps you keep track of the section you’re editing, especially when a section contains many formatting options. For example, when you scroll through color settings, the Colors and Data colors headers remain visible for context. Figure: Expanded section headers remain visible while you scroll through formatting settings. To learn more about formatting visuals, refer to Get started formatting report visualizations . Pick the axis initial scroll position ( Generally Available ) Categorical axes—like month, year, or product name—show a scrollbar when there are more categories than fit in the visual. Until now, the scrollbar always started at the beginning of the data, so the oldest values displayed first. This month, you can set Initial scroll position to End on the axis Layout section, and the visual loads with the most recent data in view. Users can still scroll back to see earlier history. The option is available on stacked, clustered, and 100% stacked bar and column charts; line, area, stacked area, and 100% stacked area charts; line and stacked column and line and clustered column charts; ribbon, waterfall, and scatter charts with a categorical X-axis. Figure: Line chart with Initial scroll position set to End on the X-axis. The scrollbar is positioned on the right, showing the most recent months first. To learn more, refer to the Customize x-axis and y-axis properties documentation. Azure Maps geocoding improvements ( Generally Available ) Large reference layers now render correctly when you filter your report. Reference layers add geographic context using points, lines, and polygons, such as locations, routes, postal codes, sales territories, and administrative regions. The Azure Maps visual renders up to 30,000 reference-layer features at a time. Previously, when a reference layer exceeded this limit, features excluded from the initial view could remain missing even after a report filter narrowed the data to a smaller area. Figure: Azure Maps visual displaying an all-up view of a US ZIP Code reference layer containing more than 30,000 polygons. Some ZIP Code boundaries are not displayed because the reference layer exceeds the rendering limit . Figure: Azure Maps visual showing the previous behavior after the report is filtered to Washington. Only ZIP Code polygons included in the initial feature set are displayed, resulting in an incomplete view of the state . Figure: Azure Maps visual showing the new behavior after the report is filtered to Washington. The full reference layer is re-evaluated, displaying all relevant ZIP Code boundaries for the state . Now, Azure Maps re-evaluates the reference-layer features whenever report filters are applied. The unfiltered view is still limited to 30,000 features, but a filtered view accurately displays the relevant features, up to that limit. On-object interaction improvements ( Preview ) Based on your feedback during preview, we're introducing the first in a series of on-object interaction improvements, designed to make quick edits to your visuals easier. This month we're refining how you add data and manage some visual elements. The Build flyout now opens only when you select Add data , helping you stay focused when dragging and dropping data directly onto a visual or into the Build pane. We’ve also separated Title and Subtitle in the Add to your visual flyout, so you can manage them independently. In addition, title and subtitle are now turned off by default for matrix, table, and card visuals in reports that use the latest base theme. New reports automatically use the latest base theme. For existing reports, select Update theme in the Theme pane to apply this change. You can turn either element back on when needed. Figure: On the left, select Add data to open the Build flyout. On the right, manage Title and Subtitle independently from the Add to your visual menu. To learn more, refer to the using on-object interaction with visuals and updating to the latest base theme documentation. Support for Fabric Apps in Org apps (Coming Soon) Soon, users will be able to include generative Fabric Apps alongside the reports, dashboards, notebooks, and other content in your Org Apps. For example, imagine you want people to rate the content in an Org App and share feedback about what would make it more useful. You can create a Fabric App for that experience and add it directly to the Org App. Figure: Adding a Fabric App item for rating an experience into an Org App and then viewing that rating experience from within the Org App. Whether you’re helping people explore what could happen next, act on an insight, or complete a specialized workflow, Fabric Apps give you a flexible new way to build for your audience without sending them somewhere else. Together, organizational apps and Fabric Apps provide a way to bring enterprise reporting, content, and tailored experiences together for your organization. Learn more about org apps and item types supported , including Fabric Apps. Changes to Power BI subscription email delivery Power BI is updating the platform used to deliver subscription emails as part of ongoing improvements to delivery reliability and long-term service health. As eligible subscriptions move to the updated platform, customers may notice changes to the sender identity and email formatting. Each subscription transfers automatically when it moves. Customers do not need to recreate it or change its schedule or recipients. Figure: After selecting Subscribe for an item, an information icon identifies a subscription that has moved to the updated email delivery platform. Learn more about changes to Power BI subscription emails . Increased Export to Excel row limits (Generally Available) Many users export Power BI data to Excel for further analysis. This month, we're increasing the maximum number of rows that can be exported from table visuals using Data with current layout from 150,000 to 500,000. This increase helps you analyze larger datasets in Excel with fewer export operations. Figure: Export data from a table visual to Excel using Data with current layout, supporting up to 500,000 row s. To learn more about exporting data from Power BI visuals, refer to Export data from a Power BI visualization . Value selection in Narrative visual We are replacing the Q&A natural language experience for creating dynamic values in the Narrative visual and text box with a more deterministic UI. This is due to the ongoing deprecation of the Q&A tool , and also based on feedback that it was hard to deterministically pick exact values through the Q&A experience. Authors can now create and edit custom values through a direct, deterministic UI: select a column or measure, apply any valid summarization, and add any type of filter. Auto-generated values are unchanged, and values previously authored with Q&A remain available as read-only. Figure: The new value selection options in the Narrative visual. To learn more, refer to the Create Smart Narrative documentation. Modeling Create and edit DirectQuery semantic models in the Power BI s ervice DirectQuery semantic models can now be created and edited directly in the Power BI service, eliminating the need to download and use Power BI Desktop. Previously, building models that query data sources in real time meant downloading Desktop, authoring the model, and publishing it to the web. Now, web-based modeling gives your team the freedom to: Work from any device: Mac, Linux and Windows users can now author DirectQuery models straight from the browser. Collaborate in real time: Multiple team members can work on the same semantic model simultaneously. Ditch the d esktop loop: Skip the download-edit-republish cycle and update your models instantly in the service. Capabilities on the web Start from scratch: Connect to a supported data source and choose DirectQuery mode. Figure : Power Query interface displaying data source connection settings, with DirectQuery selected as the data connectivity mode. Full modeling control: Open existing DirectQuery models to manage relationships, write DAX and tweak table/column properties. Figure : Model View in Power BI Service showing tables, relationships, and the properties panel for editing a DirectQuery semantic model . Flexible storage modes: Easily switch table storage modes from DirectQuery to Import or Dual if needed. Figure : Properties pane that allows user to switch table storage modes from DirectQuery to Import or Dual. Thanks to this new capability, composite models are also available on the web! Head to the Power BI service and open one of your DirectQuery semantic models or create a brand-new one. We'd love to hear what you think! Learn more in the D irect Q uery documentation. Approximate Distinct Count comes to I mport and D irect Lake (Pr eview ) Distinct count is one of the most resource-intensive operations in any analytical engine. As data cardinality grows, so do CPU and memory usage, often slowing down your interactive reports. APPROXIMATEDISTINCTCOUNT already offered a faster alternative for DirectQuery sources such as Azure SQL, Synapse, BigQuery, Databricks, and Snowflake. This month we're extending support to Import, Direct Lake on OneLake, and Direct Lake on SQL semantic models. DAX = APPROXIMATEDISTINCTCOUNT() Figure : Model View in Power BI Service showing tables, relationships, and the properties panel for editing a DirectQuery semantic model . How it works and when to use it Instead of scanning every single unique value, APPROXIMATEDISTINCTCOUNT calculates a highly accurate estimate of unique values with a standard error rate of ~1.6%. In return, you get faster query execution times. Best for high-cardinality columns : Use it on columns with millions of unique values (such as transaction IDs, user IDs, or timestamps) where an approximate result can reduce the resources required to calculate distinct values. Keep standard DISTINCTCOUNT for low-cardinality data : Stick to exact counts for smaller attributes like Country, Category, or Status, where standard calculation is already fast, or for financial metrics where absolute precision is required. Swap APPROXIMATEDISTINCTCOUNT into your heaviest measures today and let us know how much speed you gain on your models! Learn more in the APPROXIMATEDISTINCTCOUNT documentation. Accelerate text searches in your semantic models with String Indexing (Preview) String Indexing for Power BI semantic models is coming soon! If your reports rely heavily on text fields, such as product names, customer comments, or long descriptions, you’ve likely faced slow performance when users search or filter on large semantic models. String Indexing is designed to improve text-search performance in supported semantic models. Why String Indexing? Common text operations like DAX functions (SEARCH(), CONTAINSSTRING()) and advanced text slicers in reports traditionally scan data row-by-row. As datasets grow, these scans slow down query times. String Indexing builds specialized indexes so the engine can locate matching text more efficiently, which can improve report responsiveness for both Import and Direct Lake semantic models. Indexing m odes You can configure String Indexing via model metadata to fit your workload needs: Auto Mode: Automatically builds the index on the first query execution for a qualifying column. The index does not persist in storage; it remains in memory only while the column is loaded and will be rebuilt on subsequent queries if evicted. Ideal for smaller models. Full Mode: Builds and persists the index during scheduled data refreshes. While refresh times and model size may slightly increase, users enjoy consistently fast query performance right out of the box. Get s tarted String Indexing requires a semantic model running at 1707 compatibility level. During this initial preview phase, indexing can be configured through TMDL on the web or XMLA metadata. Desktop support and a dedicated UI experience within Power BI are planned for a future release to simplify setup. Figure: Setting up the “stringIndexingbehavior” property to full in TMDL view in the web. Check out the String Indexing documentation for setting up instructions, prerequisites, and guidance on choosing the right indexing mode for your models. We look forward to seeing how this feature helps make text-heavy reporting experiences faster and more responsive! Introducing Full-Text Search in Power BI Semantic Models ( Preview) Full-Text Indexing for Power BI semantic models is coming soon! While traditional string searches look for exact character matches, Full-Text Indexing enables a more intelligent search experience based on the meaning of words and natural language concepts. This capability powers two new DAX functions, TEXTCONTAINS( ) and TEXTSIMILARITY( ), making it easier than ever to analyze large volumes of textual data directly in your semantic models. Why Full-Text I ndexing ? Business data increasingly contains rich text content such as customer feedback, support tickets, product descriptions, incident summaries, and knowledge articles. Searching this data using traditional string matching often requires exact matches and can miss relevant results due to differences in spelling, word forms, or phrasing. Full-Text Indexing builds a specialized search index at the column level, allowing semantic models to understand words rather than just character sequences. This enables advanced search experiences such as: Finding related words through linguistic analysis (for example, run, running, and runs) Matching singular and plural variations automatically Ignoring common stop words such as "the" or "and" Supporting phrase-based searches Tolerating minor spelling mistakes through fuzzy matching Enabling semantic similarity search scenarios Getting Started FTS Indexing requires a semantic model running at 1708 compatibility level. During this initial preview phase, indexing can be configured through TMDL on the web or XMLA metadata. Desktop support and a dedicated UI experience within Power BI are planned for a future release to simplify setup. Figure: Setting up the “fullTextIndexingbehavior” property to full in TMDL view in the web. New DAX f unctions Full-Text Indexing is required for two new DAX functions: TEXTCONTAINS( ) Returns TRUE when a text value matches a search expression using full-text search semantics rather than simple substring matching. It supports multiple search modes, including keyword matching, phrase matching, and fuzzy matching for typo tolerance TextContains(, , [MatchMode]) Example: "Show me all reviews that mention spa ." The review either matches or it doesn't. Figure: Example of the new TEXTCONTAINS() DAX function in DAX query view. TEXTSIMILARITY( ) Returns a relevance score indicating how well the text in matches . It enables similarity-based text comparisons, helping identify records that are semantically related even when they do not contain the exact same words. TextSimilarity(, [, ]) Example: " Show me the 10 reviews most relevant to 'good breakfast'." Reviews mentioning both terms prominently rank higher than reviews that only partially match . Figure: Example of the new TEXTSIMILARITY() DAX function in DAX query view. Learn more about these two new DAX functions ( TEXTCONTAINS , TEXTSIMILARITY ) in our documentation. Full-Text Indexing is supported for both Import and Direct Lake models, with Full mode recommended (during Preview) for the best out-of-the-box performance and user experience. Refer to the F ull T ext Indexing documentation to learn more about prerequisites, configuration options, and setup instructions. Data connectivity New Power Query editor (Preview) Since May of this year, the modern Get Data experience has been available in preview inside Power BI Desktop; the feedback we've gathered from that rollout has directly shaped what comes next. Your reports of friction points, missing capabilities, and rough edges between the legacy and modern interfaces went straight into the backlog, and this month that work pays off: the full modern Power Query Editor experience moves into preview. Figure: Screenshot of the new Power Query editor using the light theme. It's the same trusted engine, wrapped in a completely refreshed editing surface — and we're still closing the remaining gaps with the legacy UI as we go. Let's explore six key reasons to enable and try this feature. Modern Get Data - The same connector browsing and search experience you already know from Fabric Dataflow Gen2 — now in Desktop. Searchable, categorized, and designed to make connectors easier to find and navigate than the legacy dialog. Try it: Connect to a new data source and browse the OneLake catalog. Figure: Screenshot of the Modern Power Query Get Data experience inside of Power BI Desktop. To learn more, refer to the Data sources in Power BI Desktop documentation. Dark theme, end to end - No more jarring light-mode panes breaking your flow. The legacy editor only partially supported dark theme. The modern editor applies it consistently across the preview grid, dialogs, and other parts of the editing surface. Figure: Screenshot of the Power Query editor using the Power BI dark theme. Folding visibility - Stop guessing whether your query folds. Step folding indicators mark each step as folding or not, and the new query plan shows exactly how the engine intends to evaluate your query — and where folding breaks down. Try it: Open the query plan on a query with several steps and find where folding stops. Figure: Screenshot of the Query Plan dialog inside of the new Power Query editor. To learn more, refer to the Understanding Query Evaluation and Query Folding in Power Query documentation. Diagram view - See how your queries relate to each other visually, instead of reverse-engineering it from names. A gamechanger for files you've inherited or models with long reference/merge chains. Try it: Open a file with referenced queries and trace a merge visually. Figure: Screenshot of the Diagram View inside of the new Power Query editor experience. To learn more, refer to the Diagram view documentation. New capabilities, now on Desktop - Features that used to live only on the web are now here: rank column, cluster values, schema view, query script view, plus upgrades to transforms you already use daily. Try it: Add a rank column or cluster values on a messy text column. Figure: Screenshot of the Schema view available in the new Power Query editor. To learn more, refer to the Rank column and Use Schema View documentation. Export a Power Query template - Capture your solution at a point in time and take it with you. Export a template from Desktop and import it straight into a Dataflow Gen2 — queries, steps, and structure intact. Try it: Export a template from a multi-query file and import it into a Dataflow Gen2 to compare. Figure : Screenshot of the Export template experience in the Power Query editor. To learn more, refer to the Power Query template documentation. Ready to try it? Enabling the modern Power Query experience takes just a few seconds — no restart required: Open Power BI Desktop. Locate: File > Options and settings > Options . Under Preview features , check New Power Query experience . Open (or reopen) the Power Query Editor — you're now in the modern experience. Once you've had a chance to explore this new user interface and its experiences, we want to hear from you. Share your thoughts on the new Power Query experience in the Fabric Community — what's working, what's missing, and what would make it a compelling alternative from the legacy editor. Every comment helps shape what ships next. Microsoft Outlook Mail connector ( Preview ) We're introducing the new Microsoft Outlook Mail connector (Preview) for Power BI Desktop. Built on the Microsoft Graph API, it lets you read your mailbox data — folders, messages, and attachments — using an organizational account. This is the first in a set of new connectors we'll be releasing as a modern alternative to the Exchange Online connector. The initial preview is scoped to Mail in Power BI Desktop. Additional connectors for Calendar Events, Contacts, and Tasks are on the roadmap, along with Excel and Power BI service / Fabric Dataflows Gen2 support. Scheduled refresh isn't supported yet — this applies to both the Power BI service and refreshes routed through the on-premises data gateway. To try it, enable the Microsoft Outlook Mail preview feature under Options in Power BI Desktop, then open Get Data → Online Services → Microsoft Outlook Mail and sign in with your organizational account. Figure: Microsoft Outlook Mail connector with the Preview badge in the Power BI Desktop Get Data experience. Figure: Microsoft Outlook Mail listed among Online Services in the Power BI Desktop Get Data pane. To learn more, refer to the Microsoft Outlook Mail connector documentation. More flexible Data Privacy Firewall query patterns in Power BI Desktop (Preview) Power BI Desktop now allows Data Privacy Firewall partitions that reference other partitions also access data sources when the privacy levels of the involved data sources are compatible. Introduced in the July 2026 release and enabled by default, this preview setting aligns Power BI Desktop with Power Query Online, gateways, and the Power BI service. This change supports common query patterns in which one query returns a value that another query uses to build a web request, SQL statement, file path, or other data source request. These patterns can now run without refactoring queries or duplicating logic solely to satisfy the previous partition restriction. The Data Privacy Firewall remains active. Power Query continues to evaluate the privacy levels of the involved data sources before combining data, helping authors use more flexible query designs while preserving privacy protections. Figure: The new Power BI Desktop preview setting allows compatible cross-partition query patterns while the Data Privacy Firewall remains active. To learn more, refer to the Allow data privacy firewall partitions that reference other partitions to also access data sources documentation. Mobile Mobile page indicator (Generally Available) Know immediately which report pages are mobile-ready, without clicking through them. Each page that has a mobile layout shows an icon on its page tab in the footer, so you can spot your mobile coverage instantly. Pages without a mobile layout stay unmarked, making it easy to see what's left to optimize. The icon is coming soon to both Power BI Desktop and the Power BI service. In Power BI Desktop, it appears in both desktop layout view and mobile layout view, so you can track mobile coverage right where you work. In the Power BI service, it appears in mobile layout view. Figure: Page tab s marked with an icon to show which pages have a mobile layout . To learn how to build mobile-optimized reports, refer to the Mobile-optimized Power BI reports overview documentation. Contact details in Info drawer ( Generally Available ) We’re making it easier to connect with the right people from the Power BI Mobile app. You can now find contact details in the Info drawer for reports, apps, and dashboards, and email the relevant contact directly from your phone. Figure: Two Power BI Mobile screens showing the Contoso Sales workspace and the report’s Info drawer with a clickable contact name for sending an email. To learn more about Power BI in mobile, refer to the What Are the Power BI Mobile Apps? documentation. Developers and APIs Power BI Project s ( PBIP) (Generally Available) Since entering preview in 2023, PBIP has changed how developers build and manage Power BI content. It stores report and semantic model definitions as human-readable text files, turning a Power BI solution into a codebase. Developers can search these files, track changes in Git, review diffs in pull requests, automate updates with scripts and pipelines, and use AI agents to work with models and reports. Changes remain visible and reversible, which makes team development easier and safer. Recent improvements have made the workflow more practical. These include opening a project directly in Visual Studio Code and detecting external file changes in Power BI Desktop . Figure: Open Visual Studio Code entry point in Power BI Desktop. New underlying formats capabilities: Tabular Model Definition Language (TMDL) for semantic models. Power BI Enhanced Report Format (PBIR) for reports. PBIR is now the default report format for PBIX and PBIP files. New reports use it from the start. When you edit a report that uses the legacy format, Power BI tools automatically convert it to PBIR. To learn more, refer to the Power BI Projects documentation. New Purge Data option for Fabric APIs The new Purge Data option for Fabric APIs gives developers and administrators greater control over programmatic semantic model deployments. This capability allows users to explicitly approve deployments that may require removing existing data, helping unblock scenarios such as schema or data type changes that previously failed validation checks. Designed with both safety and automation in mind, purgeData keeps data protection safeguards enabled by default while giving developers the flexibility they need to manage complex deployment scenarios at scale. To learn more, refer to the Purge Data documentation. Other Data updated and sensitivity fields of Power BI report in Microsoft Teams preview card (Coming Soon) Power BI report previews in Microsoft Teams will soon surface the report's last refresh date and sensitivity label. These additional signals will help users quickly assess the freshness, relevance, and classification of a report before opening it. Figure: Power BI report preview card in Microsoft Teams chat showing report metadata, including the last refresh date and sensitivity label. To learn how Power BI content is displayed in Microsoft Teams, refer to the Link preview cards in Microsoft Teams chats and channels documentation. Artifact info header for Power BI tabs in Microsoft Teams (Generally Available) Power BI content in Microsoft Teams tabs now includes the artifact info header, giving users the context they need without leaving their flow of work. Available for reports, apps, organizational apps, dashboards, and scorecards, the header brings key artifact information and actions together in one place. The new header displays the artifact name and sensitivity label and provides an entry point to artifact metadata. You can open the artifact in the Power BI personal app in Teams, open it in a browser, and refresh the tab. Tab owners can control their experience with the new Show info header setting on the tab settings page. The setting is 'on’ by default and can be turned off when a more compact tab experience is preferred. Figure: Power BI report in a Microsoft Teams tab with the artifact header open, displaying report metadata. Figure: Power BI report in a Microsoft Teams tab, with the setting dialog open. To learn how to add Power BI content as a tab in Microsoft Teams, refer to the Embed Power BI reports in Microsoft Teams documentation. Third - party custom visuals graphomate matrix The graphomate chartrix is a brand-new charting visual, and it offers various improvements over graphomate charts. First and probably most obvious is the new interactive user interface which enables users to define most elements of the chart layout directly on the visual. To keep this interface effective and uncluttered it focuses on the most important parameters of your chart. Users can now create combination charts which were simply not possible before. There are also new chart types like the variance waterfall, which automatically renders from one measure and two dimensions. Of course, the graphomate chartrix is IBCS® certified. With the latest release an XFL editor has been introduced, which helps you write scripts to format the chartrix far beyond the possibilities of the regular option set. XFL scripts also provide a way to conditionally format the visualization, dynamically changing properties in relation to the actual data. This new visual is provided free of charge to existing customers of the graphomate charts. All development efforts will be focused on making the graphomate chartrix the best IBCS® charting visual there is. Video Link: graphomate chartrix for Microsoft Power BI AppSource Link: graphomate chartrix Sample Report Link Drill Down Bubble PRO by Zoom C harts Drill Down Bubble PRO is a Power BI visual designed for exploring relationships, trends, and outliers across multiple dimensions of data. It adds richer exploration, selection, and analytical capabilities directly inside the visual. Key features include: Multi-level drill down to explore data hierarchies from a high-level overview to detailed insights. Pan and zoom controls to navigate dense datasets and focus on specific clusters or individual data points. Area and lasso selection to quickly isolate groups of bubbles and use selections for interactive analysis and filtering. Dynamic regression lines that recalculate as the displayed data changes, making trends and relationships easier to identify. Line and area thresholds to highlight targets, ranges, exceptions, or other important business benchmarks. Area shading to visually group and compare selected segments of data. 200+ formatting settings to tailor the chart to different reporting and branding needs. Figure: Drill Down Bubble PRO demonstrates multi-level drill down, panning, and zoom controls for exploring data from high-level patterns to detailed points. These capabilities make Drill Down Bubble PRO especially useful for customer segmentation, sales analysis, portfolio analysis, performance monitoring, and other scenarios where users need to actively explore patterns rather than simply display them. Get on Markeplace Commenting in view mode: introducing Zebra BI Tables+ & Charts+ It's month-end. A regional manager opens the report, spots a variance in their region, and knows exactly why it happened. But the report isn't theirs to edit, so the explanation ends up where it always does: a screenshot pasted into PowerPoint, emailed around, detached from the number that prompted it. That's the collaboration gap. Your report shows what happened; the why and the what next leave the report and get lost. Meet Zebra BI Tables+ and Charts+ : two new visuals that keep everything existing Zebra BI Tables and Charts offer and add a built-in collaboration layer . Report viewers can add comments directly on a data point, in view mode, with no Power BI edit access. Each comment is anchored to the exact figure and stored in your own SharePoint file. Zebra BI stores nothing. Figure: Zebra BI Tables+ and Charts+ enable report viewers to add contextual comments to individual data points, attach supporting files from SharePoint, and collaborate directly in view mode. So instead of screenshotting insights into PowerPoint or maintaining a custom workaround, the whole team explains and decides right on the report. Instead of slides or emails, the next steps can be defined directly on the spot. Stop losing good decisions to a missing context. Start making them on the report. Try Zebra BI Tables+ and Charts+ free for 14 days on AppSource. Network Graph by Powerviz The Powerviz Network Graph is a visual representation of Nodes and the relationships or connections between them. Its primary purpose is to illustrate how different entities are related or interact with one another. Key Features Line Options : Customise node links with different styles and colors. Node Shape : Choose from various shapes, icons, or upload your own. Labels : Display categories, values, and percentage labels. Data Colors : Access 30+ color palettes, including color-blind-safe options. Fill Patterns : Highlight nodes with patterns or upload your own. Conditional Formatting : Highlight outliers based on measures or category rules. Clusters : Group related nodes to reveal patterns. Relationships : Analyze node connections at a glance. Animation : Add pop-ups and highlight effects. Import/Export : Save and reuse themes easily. Toolbars : Gain advanced control over the graph. Other features included are Sorting, Ranking, Lasso / Reverse Lasso, Grid View and more. Business Use Cases Customer Relationship Management (CRM), Supply Chain Optimization, Social Network Analysis (SNA). Figure: Customize every connection, cluster, and node to build a Network Graph that truly fits your data. Figure: Go beyond connections with powerful colors, patterns, labels, formatting, and interactive controls. Resources Try Network Graph visual for FREE from AppSource Check out all features of the visual Step-by-step instructions YouTube Video Learn more about visuals Follow Powerviz on LinkedIn Hierarchical Bar Chart New, exciting changes were made to Hierarchical Bar Chart. Bubble Matrix for stacks - The visual now provides the option to show stacks as bubbles below the bars. Figure: Hierarchical Bar Chart transforms stacked period values into bar-and-bubble matrix layouts for clearer comparison of category totals and component contributions. Display Stacks as Clustered Columns - From the format pane settings, you can choose to display stacks as clustered column chart. Figure: Hierarchical Bar Chart displayed as clustered columns, with period targets and variance indicators configured from the Format visual pane. Filter using legends - You can click on a stack legend to filter out other stacks. On mouse hover relevant stack gets highlighted. Stack ribbons and %age of total - You can now choose to connect stacks with ribbon and show percentage of total for each stack. Resources Check out the Hierarchical Bar Chart Update YouTube video. Download the visual from APPSOURCE Download a sample pbix file For more information refer to Hierarchical Bar Chart or contact us . That’s a wrap! The European Microsoft Fabric + SQL Community Conference is just getting started, and there's never been a more exciting time to be part of the Power BI community. We hope these updates help you discover new capabilities, streamline your workflows, and get even more value from your data. Be sure to explore the links throughout this post for deeper technical guidance and follow along with the latest announcements and sessions from Barcelona.

Retirement: Azure Deployment Environments will be retired on February 22, 2027

Thu, 08 Oct 2026 18:20:34 +0000

Azure Deployment Environments will retire on February 22, 2027. Beginning on September 14, 2026, Azure Deployment Environments will begin the closing-down process. After retirement, the service will no longer be available. To help avoid disruption, we rec

Are bigger agents better? How to design agents that scale

Thu, 08 Oct 2026 18:18:59 +0000

There is a moment every maker hits. An agent works, so you add another tool. Then another knowledge source. Then instructions for an exception that appeared last week or an entirely new use case you want your agent to be able to tackle. Each addition is useful on its own, and the agent can now do more. But "can do more" and "reliably does the right thing" are different properties. As an agent’s scope increases, the model has more choices to distinguish, more context to process, and more possible execution paths to manage. That doesn’t mean large agents are bad. It means that as capability grows, the challenge increasingly becomes a design problem. The key to scaling an agent isn't giving it more. It's being deliberate about what it sees, what it decides, and what it delegates. What changes as an agent grows The agent scaling challenge Consider a supplier-onboarding agent. The first version collects supplier details, checks that the request is complete, and starts an approval. Over time, makers add tools for ERP records, tax validation, sanctions screening, bank verification, contract storage, service tickets, email, and reporting. They add knowledge for regional policies and instructions for exceptions. Eventually, a request such as "Onboard our newest supplier" might present the agent with several supplier-search tools, multiple ways to create or update a record, and overlapping policy sources. The agent still has all the required capabilities, but choosing the right path is harder. The agent scaling challenge tends to show up in four places: Selection: Similar tool names and descriptions make the correct action harder to identify. Context: Tool definitions, instructions, knowledge, conversation history, and tool outputs all compete for a finite context window. Execution: More possible paths create more opportunities for unnecessary calls, retries, and inconsistent outcomes. Operations: A larger capability surface is harder to evaluate, secure, govern, and maintain. A recent post from Microsoft Research discusses one part of this problem: Tools that work well independently can reduce end-to-end performance when they compete in a large or overlapping set. Often, the problem isn’t one bad tool. It is the ambiguity between several reasonable ones. Figure 1: As a supplier-onboarding agent grows, overlapping tools, instructions, and knowledge compete for attention before the agent begins the task. More context comes with a cost There is also a direct cost associated with an expanding toolset. A tool consumes tokens even when it is never called because its name, description, and parameter schema are included in the context presented to the model. When it is called, its output becomes part of the agent's ongoing context. More context can mean more spend, as well as less reliable selection. The goal isn’t a smaller agent. It is a system where each decision sees only the context, authority, and capabilities it needs. Success is measured by business outcomes, reliability, cost, and control. What our harness can handle for you Good agent architecture doesn't mean solving every scaling challenge yourself. The GitHub Copilot harness in Copilot Studio is built to manage some of the complexity as an agent grows. Model improvements that don’t require agent redesign New models are made available through the GitHub Copilot harness as they release. As more advanced frontier models become available, teams can evaluate them against their scenarios and adopt improvements without redesigning the overall solution architecture. Model choice can also be an important factor in agent cost optimization, helping makers balance the number of tokens used against the capability needed to achieve a goal. Manage complexity natively with tool search The GitHub Copilot harness includes runtime capabilities designed for reasoning-heavy, multistep work. One example is tool search . When the available tool set becomes large, tool search can hold external tool definitions back and load the relevant ones on demand instead of placing every full schema in the model's context. For the supplier-onboarding request, this can narrow a large catalog to the tools associated with finding a supplier, validating its details, and starting onboarding. The model works with a smaller, better-matched set of choices while unrelated tool definitions remain out of the way. The harness can also plan across tools, skills, workflows, MCP servers, files, and connected agents, and adjust its path as work progresses. This all makes large, reasoning-heavy automations more practical. But runtime capabilities only solve part of the scaling challenge. How you divide responsibilities across tools, workflows, skills, and connected agents still matters. How to design agents that scale in Copilot Studio A scalable design starts by deciding which part of the system should own each responsibility. For instance: Use a tool for a bounded action or lookup with a clear input and output. Use a workflow when a sequence, approval, or business rule should execute consistently. Use a skill for specialized instructions that are only needed for a particular task. Use a connected agent when a domain has distinct context, ownership, or requirements. Use the main agent to coordinate outcomes, gather information, make judgments, and handle exceptions. These are not interchangeable building blocks. Each introduces different tradeoffs in context, flexibility, latency, cost, security, and maintenance. The goal is to use the simplest component that gives each responsibility a clear owner. 1. Make choices distinct Start with the choices already available to the agent. Give tools, knowledge sources, and connected agents specific names and descriptions that explain both what they do and when they should be used. Merge or remove duplicate capabilities. Avoid several general-purpose tools that all appear to answer the same intent. In the supplier example, "Search suppliers in ERP by legal name or tax ID" is easier to select correctly than a generic tool named "Search." If two tools search the same supplier records, expose one clear route rather than asking the model to choose between implementations. Tool search itself relies on names, descriptions, and parameter metadata to find relevant tools, so good metadata improves both discovery and final selection. 2. Load specialist guidance only when it is needed Some instructions are only relevant when an agent performs a particular task. Keeping all of them in the main agent instructions means they occupy context on every turn, even when they do not apply. Skills let makers package specialized instructions separately so the agent can load them when the task requires them. For example, regional supplier due-diligence guidance can be packaged as a skill and loaded for suppliers in that region, rather than remaining in the main instructions for every supplier request. The principle is the same as tool search: keep relevant context close and leave unrelated context out of the current decision. 3. Split on real boundaries When one agent contains several distinct domains, consider separating them. To clarify: Don't split an agent simply because it has grown large. Split where there is a meaningful boundary in context, ownership, security, or requirements. In the GitHub Copilot harness, connected agents let a primary agent delegate a bounded task to another Copilot Studio agent with its own instructions, knowledge, tools, and orchestration context. The supplier-onboarding agent could remain the front door while delegating: Compliance assessment to a compliance agent owned by the risk team. Supplier record creation to a finance operations agent with access to the ERP. Contract preparation to a legal operations agent with its own templates and policies. The primary agent now chooses between a few clearly described business capabilities instead of dozens of lower-level tools. Each specialist can be evaluated, secured, deployed, and improved independently. Copilot Studio also supports open agent architectures. Depending on the runtime and scenario, solutions can compose Copilot Studio agents or connect supported external agents through the Agent2Agent protocol. In the supplier scenario, a specialist due-diligence agent hosted outside Copilot Studio could sit behind the same clear boundary, rather than being rebuilt as a collection of tools. 4. Put fixed sequences in workflows Use the agent where the next step requires judgment. Use a workflow where the sequence, approval, or control must remain consistent. This helps preserve adaptability without making every part of the process probabilistic. For example, supplier onboarding might always require the same core sequence: validate required fields, check for an existing supplier, run mandated compliance checks, create the record, and route it for approval. A workflow can own that sequence. The agent can still decide when to start it, gather missing information, and handle exceptions. This reduces the number of low-level decisions the model must make and gives makers one place to enforce approvals, retries, and audit requirements. The supplier-onboarding agent, redesigned So let’s go back to the original agent in our example. It had one long instruction set, several knowledge sources, and dozens of tools. The redesigned system doesn’t eliminate that agent. It gives it a clearer job: coordinating the overall outcome while other components take on more specialized responsibilities. That gives us a system: The main supplier-onboarding agent understands the request, collects any needed details, delegates as needed, handles exceptions, and responds. Tool search limits the external tools loaded for the current request. Clear metadata separates supplier lookup, compliance, finance operations, and contract tasks. A workflow owns the fixed onboarding and approval sequence. Skills provide regional guidance only when the supplier's location requires it. Connected agents own compliance, ERP, and legal domains where those boundaries justify separate agents. Figure 2: The same capability as a composed system: a coordinating agent retains judgment, the harness discovers relevant tools, workflows own fixed sequences, and specialist agents own bounded domains. The result is the same overall capability, but as a composed system with clearer responsibilities and less for any one decision to reason over. Evaluate for the outcome Each approach discussed above has limits. A stronger model cannot compensate for unclear instructions or overlapping tools. Tool search reduces what the model sees, but it does not create boundaries that have not been designed. Workflows and skills reduce what the main agent must reason over, but they add components to maintain. And connected agents can provide clearer ownership and security boundaries, but each handoff adds token use, another failure point, and more to govern. Designing agents that scale means managing all four components of the agent scaling challenge together: making selection easier with distinct choices and clear boundaries, controlling context with tool search and skills, making execution more predictable with workflows and deliberate delegation, and strengthening operations through components that can be evaluated, secured, governed, and improved independently. Agent scale is not a tool-count contest. Models, requirements, and available tools will keep changing, but these principles give you a more durable way to evolve an agent without letting added capability become added confusion. The goal is not the biggest agent; it is a composed system that reliably does the right work, at the right cost, with clear ownership.

Synced iCloud Keychain passkey registration succeeds despite Device-Bound-only passkey profile

Thu, 08 Oct 2026 18:07:47 +0000

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } We have Microsoft Entra passkeys enabled only for a pilot group. The assigned Default Passkey Profile is configured as: Passkey Type = Device-bound Key Restrictions enabled Microsoft Authenticator iOS and Android AAGUIDs only Despite this, a pilot account successfully registered a synced iCloud Keychain passkey. The Security Info page explicitly shows: "Passkey (Synced) - iCloud Keychain" The tenant also displays a warning banner stating: "All users enabled for SMS or voice authentication are in scope for passkey auto-enablement and will be assigned to a system-managed passkey profile that allows all passkey types without restrictions." Can Microsoft explain how tenant-managed passkey profiles interact with the system-managed passkey auto-enablement profile? Is the system-managed profile overriding or supplementing tenant-defined passkey restrictions?

The Bigger the Judge, the Better the Judgment? Not Quite.

Thu, 08 Oct 2026 18:00:00 +0000

I tested three sizes of Kev and hosted JEV against security evidence, reordered choices, reassuring text and claims of authority. Bigger models were more stable, but that wasn't the whole story. And the results sent me down another architectural rabbit hole.

Where Community and Code Connect: MVPs at Nebraska.Code 2026

Thu, 08 Oct 2026 17:46:50 +0000

A tech community worth traveling for Nebraska may not be the first place that comes to mind when people picture a major technology conference. Yet Nebraska.Code 2026 has created something remarkable in Lincoln, Nebraska: a gathering where developers, engineers, and technology professionals come together to learn, connect, and share what is working in the real world. Microsoft MVPs traveled from across Canada and the United States to participate - not only by presenting technical sessions, but also by exchanging ideas, answering questions, and strengthening a community built on curiosity and generosity. “What I love most about Nebraska.Code is the community feel. I feel like I’m learning among friends.” - Rob Richardson, Microsoft MVP MVPs at Nebraska.Code (left to right) - Jonathan "J" Tower (MVP), Brian Gorman (MVP), Debra Benkovich (community member), Mike Benkovich (MVP) More than sessions: a shared experience The MVPs and Regional Directors who joined Nebraska.Code brought expertise across AI, software development, cloud architecture, and the human side of a career in technology. Richard Campbell , a Microsoft Regional Director and MVP, opened the event with the keynote “Beyond the AI Hype: What’s Real, What’s Next,” helping attendees distinguish today’s practical AI capabilities from the ideas still taking shape. The sessions that followed addressed questions many technologists are navigating now: How should developers adapt to AI and agentic coding? How do teams choose among infrastructure-as-code tools such as Terraform, Bicep, and Pulumi? How can people sustain fulfilling careers while balancing work, life, and stress? Together, the keynote and sessions made space for both immediate technical decisions and a clearer view of what may be coming next. Spencer Schneidenbach helped developers consider how to adapt to a fast-changing development landscape shaped by AI and agentic coding. Mike Benkovich compared infrastructure-as-code options, exploring where Terraform, Bicep, and Pulumi fit and the tradeoffs involved so attendees could make informed choices rather than simply follow the latest trend. Mitchel Sellers brought a candid perspective on balancing work, life, and stress over the course of a technology career. Rather than presenting abstract predictions, the speakers grounded their ideas in practical experience. Attendees could compare options, challenge assumptions, and leave with approaches they could test in their own teams. The learning continued after the sessions as participants asked follow-up questions and connected the speakers’ insights to their own work. “Nebraska might not be the first place people think of when they think about major tech conferences, but Nebraska.Code has built something special.” - Mike Benkovich, Microsoft MVP But the experience extended far beyond presentation rooms. Rob Richardson described the conference as learning among friends - reconnecting with familiar faces while sitting alongside one another to discover something new. That combination of deep technical content and genuine connection is why speakers return and why attendees make the trip to Lincoln. “Being an MVP gives me opportunities to share what I’ve learned, and at Nebraska.Code that meant talking about teaching developers how to adjust to the new world of AI and agentic coding.” - Spencer Schneidenbach, Microsoft MVP Speakers at Nebraska.Code get a hand sewn custom robot figure as a speaker gift. (left to right) Kenneth Versaw (Nebraska.Code co-founder) and Mike Benkovich (MVP) The ripple effect of showing up Community conferences create impact at several levels. Attendees leave with practical ideas they can apply to their work. Speakers sharpen their thinking through questions and conversations. New professional relationships begin over hallway discussions, shared meals, and the simple act of learning together. That exchange can be especially meaningful at a regional event. Attendees gain direct access to speakers and peers they might otherwise encounter only online or at much larger conferences. Presenters, in turn, hear from developers across different organizations, industries, and career stages. Those conversations ground the learning in real experience and often send speakers home with new perspectives. This ripple effect is central to the Microsoft MVP community: MVPs are recognized not only for their technical expertise, but also for sharing it in ways that help others move forward. At Nebraska.Code, that spirit was visible in sessions focused on emerging tools and enduring career challenges alike. As Sellers put it, sharing knowledge matters because “you never know who you will meet, or how far your impact may go.” “People who overlook conferences in places like Nebraska are missing out on some of the nicest people in tech!” - Mitchel Sellers, Microsoft MVP The conference also shows why strong technology communities can thrive anywhere. Nebraska.Code brings hands-on workshops, breakout sessions, lightning talks, and connections to Lincoln, creating a regional hub with reach far beyond the state. Its setting is part of what makes it memorable: approachable speakers, thoughtful conversations, and a community that welcomes people into the learning process. Mike Benkovich (MVP) presenting at Nebraska.Code. Keep learning. Keep sharing. If Nebraska.Code sparks your curiosity, explore the conference, follow the speakers whose ideas resonated with you, and look for a community event near you. Learn more about the RDs and MVPs that spoke at Nebraska.Code Alec Harrison, Barry Stahl, Ben Dachrai, Brian Gorman , Cory House, Duane Newman, Jonathan "J" Tower, Joseph Guadagno, Mike Benkovich , Mitchel Sellers, Richard Campbell , Rob Richardson , Spencer Schneidenbach , Samuel Gomez, Scott Sauber, and Vaibhav Gujral through their MVP profiles. If you are already sharing knowledge, mentoring others, creating resources, or bringing technologists together, explore the Microsoft MVP Program . Community impact often begins with one useful idea shared generously - and you never know how far it may travel. Want to Learn More About the MVP Program? To find an MVP and learn more about the Microsoft MVP Program, visit the MVP Communities website and follow program updates on LinkedIn or through #MVPBuzz. Join us for a future live session through the Microsoft Reactor where we walk through what the MVP program is about, what we look for, and how nominations work. These sessions are designed to help you connect the dots between the work you’re already doing and the impact the MVP Program recognizes - with time for questions, examples, and real conversations.

[Launched] Generally Available: Exceptions in WAF for Azure Application Gateway and Azure Front Door

Thu, 08 Oct 2026 17:29:30 +0000

Announcing the general availability of exceptions for Web Application Firewall on Azure Application Gateway and Azure Front Door.Azure Web Application Firewall (WAF) helps protect your web applications from common threats and attacks. In some cases, WAF m

Earn the Digital Sovereignty specialization and stand out in a growing market

Thu, 08 Oct 2026 17:26:35 +0000

Customers are raising digital sovereignty requirements earlier in the sales cycle as they navigate AI adoption, evolving regulations, cybersecurity risks, and operational resilience concerns. Microsoft partners who can confidently address these challenges can position themselves to serve as trusted advisors and capture emerging opportunities. The Digital Sovereignty specialization validates your capabilities delivering secure, compliant, and locally governed cloud solutions using Microsoft Sovereign Cloud. Demonstrate your expertise to customers seeking guidance on data control, governance, sovereign AI, cloud resilience, and regulatory requirements. As demand for sovereignty expertise grows across regulated and public sector industries, now is the time to differentiate your practice and showcase your proven capabilities. Learn how digital sovereignty is reshaping customer priorities in the blog and explore the requirements, benefits, and business opportunities associated with earning the Digital Sovereignty specialization .

[In preview] Public Preview: Microsoft Agent 365 integration with Azure API Management

Thu, 08 Oct 2026 17:24:34 +0000

The integration between Microsoft Agent 365 and Azure API Management is now available in public preview, helping organizations connect centralized governance with runtime enforcement for MCP servers and tools.With this integration, organizations can:Disco

Finding the Elusive MDE PUA Audit Events on Linux

Thu, 08 Oct 2026 17:17:13 +0000

Potentially Unwanted Applications, or PUA, they aren't necessarily malware, but they are applications you probably don't want running across your environment either. Microsoft defines potentially unwanted applications as software that can adversely affect endpoint performance or use. Examples include advertising software, software bundlers, and applications that use behaviors intended to evade security products. Microsoft Defender can also consider an application's reputation when determining whether software qualifies as potentially unwanted. That sounds straightforward. On Windows, it generally is. On Linux, finding the resulting audit events requires knowing exactly where to look. And that is where things get interesting. PUA, PUP… Same Neighborhood, Slightly Different Address Before going further, it is worth clearing up some terminology. Across the security industry, you will commonly encounter both PUP , or Potentially Unwanted Program , and PUA , or Potentially Unwanted Application . The terms are frequently used for software that isn't necessarily malicious but has characteristics that make its presence undesirable, such as intrusive advertising, bundling additional software, or other behavior the user might not have knowingly requested. Microsoft uses Potentially Unwanted Application (PUA) as its product and detection terminology. Microsoft specifically distinguishes PUA from malware. A PUA might cause poor system performance, display unexpected advertisements, install other software, or have a poor reputation because of undesirable behavior, but those characteristics don't automatically make the application malware. Microsoft's classification criteria include examples such as: Advertising software that displays advertisements or promotions, including injecting advertisements into webpages. Bundling software that offers to install additional software that isn't digitally signed by the same entity, or that itself qualifies as PUA. Evasion software that actively attempts to avoid detection by security products or behaves differently when security software is present. Applications that have developed a poor reputation based on undesirable behavior. Microsoft's broader software-classification model also distinguishes between unknown software, malware, unwanted software, and other classifications. Software can therefore be legitimate and functional while still meeting Microsoft's criteria for classification as potentially unwanted. For the rest of this article, we'll use PUA , because that is the terminology used by Microsoft Defender and, more importantly for our investigation, the Linux product logs identify these detections explicitly as: potentially_unwanted_application That string is going to become very useful once we start looking for the supposedly elusive audit events. PUA Audit and Block on Windows On Windows, PUA protection is part of Microsoft Defender Antivirus. Administrators can configure Defender to identify applications that Microsoft considers potentially unwanted and determine how those applications should be handled. Microsoft documents PUA protection and provides the AMTSO Potentially Unwanted Application test file ( Feature Settings Check - Potentially Unwanted Applications - AMTSO ) as its standard demonstration scenario. Microsoft's demonstration documentation identifies Windows, Windows Server, macOS, and Linux among the supported operating systems for the PUA demonstration. The two operating modes we're interested in are conceptually simple: Audit Defender identifies the PUA but doesn't block it. This is useful when you want to understand the potential impact of enabling PUA protection before enforcing it. Block Defender identifies the PUA and takes the configured protection action. On Windows, for a device onboarded to Microsoft Defender for Endpoint – that telemetry and audit information is available in the XDR Security portal. You can find PUA detections in the Additional Fields of the AntivirusDetection action type in the DeviceEvents table – and an alert will fire when in PUA is in block mode: DeviceEvents | where ActionType == "AntivirusDetection" | extend x = parse_json(AdditionalFields) | project Timestamp, DeviceName, FolderPath, FileName, SHA256, ThreatName = tostring(x.ThreatName), WasExecutingWhileDetected = tostring(x.WasExecutingWhileDetected), WasRemediated = tostring(x.WasRemediated) | where ThreatName startswith_cs 'PUA:' Microsoft Defender Antivirus events can be investigated through: Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational Defender detection events can provide information such as the threat name, threat ID, category, path, detection origin, detection type, and detection source. That makes auditing and troubleshooting reasonably familiar territory for Windows administrators. The experience on Linux, however, is different. PUA Protection on Linux Microsoft Defender for Endpoint on Linux also supports PUA protection. Microsoft documents three PUA actions: Off: PUA protection is disabled. Audit: PUA files are reported in the product logs, but no remediation is performed. Block: PUA files are reported and action is taken against them. The distinction between Audit and Block is particularly important. In PUA Audit mode : PUA files are reported in the product logs. They aren't reported in the Defender portal through this PUA mechanism. No infection record is stored in threat history. No action is taken against the file. In Block mode : The detection is reported in the product logs. It is reported in the Defender portal. A record is stored in threat history. Defender takes action on the PUA. PUA behavior can be configured locally with mdatp. To configure Audit: sudo mdatp threat policy set --type potentially_unwanted_application --action audit To configure Block: sudo mdatp threat policy set --type potentially_unwanted_application --action block There is one important distinction worth calling out here: PUA Audit mode isn't the same thing as the broader Microsoft Defender for Endpoint Antivirus Passive Mode on Linux. PUA Audit is specifically the handling policy for applications that are detected and classified as potentially unwanted. For this article, we're testing and focusing on PUA Audit . A Windows PUA on Linux? Yes. Here's where the test gets more interesting. The AMTSO PUA test artifact is a Windows executable. At first glance, that doesn't seem particularly useful when we're trying to validate PUA protection on Linux. After all, we're testing on Linux. But Defender's file inspection isn't limited to applications that can execute natively on the operating system. A Windows PE file sitting on a Linux filesystem can still be inspected and classified. And we can demonstrate that directly. Microsoft's PUA demonstration directs administrators to the AMTSO Potentially Unwanted Application test file, and Microsoft's current demonstration documentation includes Linux among the supported operating systems. On our Linux test machine, we downloaded: PotentiallyUnwanted.exe The important point is that we don't need to execute the Windows executable on Linux. In our testing, simply causing filesystem activity against the file was sufficient to make Defender inspect it. The file initially resided in: /home/ritter/Downloads/PotentiallyUnwanted.exe We then used the Linux graphical file manager to move it into: /home/ritter/Music/PotentiallyUnwanted.exe That was enough to generate another PUA Audit observation. The Defender record showed: "scan_reason":"move" And, more importantly, Defender classified the file as: "name":"PUA:Win32/EICAR_Test_File" with: "type":"potentially_unwanted_application" and: "status":"infected" The event also recorded information about the process responsible for the filesystem operation. In our test, moving the file graphically resulted in the process being recorded as: /usr/bin/nautilus So although the test artifact is a Windows executable, MDE running on Linux still inspected and classified it as PUA:Win32/EICAR_Test_File. That's exactly what we needed. So Where Is the Audit Event? This is the elusive part. If you immediately start looking in the Defender portal or expect PUA Audit to behave like PUA Block, you're likely to come away wondering whether anything happened. Microsoft's Linux documentation tells us that Audit-mode PUA files are reported in the product logs and that no infection record is stored in threat history. Fair enough. But that naturally leads to another question: Which product log? Instead of guessing, we asked Linux. A recursive grep across the MDE log directory provides a simple way to find anything containing the PUA classification string: sudo grep -RniH 'potentially_unwanted' /var/log/microsoft/mdatp/ Where: R searches recursively. n displays the matching line number. i makes the search case-insensitive. H forces grep to display the filename. And there it was. On our test system, the PUA Audit records were located in: /var/log/microsoft/mdatp/microsoft_defender_core_err.log If you only want to determine which log files contain PUA records: sudo grep -Rli 'potentially_unwanted' /var/log/microsoft/mdatp/ Once you've identified the log, you can search it directly: sudo grep -ni 'potentially_unwanted' /var/log/microsoft/mdatp/microsoft_defender_core_err.log Or include surrounding lines for additional context: sudo grep -ni -B5 -A10 'potentially_unwanted' /var/log/microsoft/mdatp/microsoft_defender_core_err.log Our test produced records containing information similar to: [Audit]: Source: { "$type":"real_time", "scan_reason":"move", "process":{ "path":"/usr/bin/nautilus" } }, File: /home/ritter/Music/PotentiallyUnwanted.exe, Threat: { "name":"PUA:Win32/EICAR_Test_File", "type":"potentially_unwanted_application", "status":"infected" } And there it is. The PUA audit event exists. You just have to go spelunking through the local Defender product logs to find it. The Microsoft documentation is technically correct: PUA Audit detections are written to the product logs. Knowing what string to search for and which log actually contained the events on our test system makes that guidance considerably more actionable. That's Fine for One Server. What About 1,000? Running grep on a test machine is easy. Running grep individually across hundreds or thousands of Linux servers obviously isn't the operational model we want. Once we know where the information resides, however, the problem changes from a Defender problem into a log collection problem . And that's a much easier problem to solve. One option is Azure Monitor Agent (AMA) . AMA supports collecting custom text logs from Linux systems through an Azure Monitor Data Collection Rule (DCR) and sending those records to a Log Analytics workspace. Conceptually: A DCR can be configured to collect the Defender text log identified during testing. Azure Monitor supports Linux custom-text-log file patterns and wildcards for appropriate log-file collection scenarios. Azure Monitor Custom Text Logs also supports ingestion-time transformations, allowing records to be filtered or formatted before they're written to the destination table. That creates an interesting opportunity. Rather than collecting every line from a verbose Defender diagnostic log, a collection strategy could focus on the records containing: potentially_unwanted_application Once centralized in Log Analytics, those records become queryable with KQL. For example, if the records were ingested into a custom table called MDEPUAAudit_CL, an initial investigation could start with: MDEPUAAudit_CL | where RawData contains "potentially_unwanted" From there, the raw records could be parsed for useful reporting fields including: Host Timestamp File path Detection name PUA classification Scan reason Initiating process First occurrence Last occurrence Number of observations Turning Audit Mode into a Deployment Tool This is ultimately where the exercise becomes useful. PUA Audit doesn't have to be merely a configuration checkbox. It can become a pre-enforcement assessment mechanism . The workflow looks something like this: Instead of asking: "What happens if we turn PUA Block on?" we can start answering a much better question: "What has Defender already identified as PUA while we've been running in Audit?" And now we know where the answer is hiding. Reference Live link Detect and block potentially unwanted applications with Microsoft Defender for Endpoint on Linux https://learn.microsoft.com/en-us/defender-endpoint/linux-pua Detect and block potentially unwanted applications with Microsoft Defender Antivirus https://learn.microsoft.com/en-us/defender-endpoint/detect-block-potentially-unwanted-apps-microsoft-defender-antivirus How Microsoft identifies malware and potentially unwanted applications https://learn.microsoft.com/en-us/unified-secops/criteria Potentially unwanted applications (PUA) demonstration https://learn.microsoft.com/en-us/defender-endpoint/defender-endpoint-demonstration-potentially-unwanted-applications AMTSO Feature Settings Check: Potentially Unwanted Applications https://www.amtso.org/feature-settings-check-potentially-unwanted-applications/ Microsoft Defender Antivirus event IDs and error codes https://learn.microsoft.com/en-us/defender-endpoint/troubleshoot-microsoft-defender-antivirus Microsoft Defender for Endpoint on Linux resources https://learn.microsoft.com/en-us/defender-endpoint/linux-resources Collect text file from virtual machine with Azure Monitor https://learn.microsoft.com/en-us/azure/azure-monitor/vm/data-collection-log-text Collect logs from text files with Azure Monitor Agent and ingest to Microsoft Sentinel https://learn.microsoft.com/en-us/azure/sentinel/connect-custom-logs-ama Collect guest log data from virtual machines with Azure Monitor https://learn.microsoft.com/en-us/azure/azure-monitor/vm/data-collection DeviceEvents table in the Advanced Hunting schema https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-deviceevents-table Microsoft Defender XDR Advanced Hunting schema tables https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-tables

Partner Blog | Build your digital sovereignty practice now

Thu, 08 Oct 2026 17:00:00 +0000

Turn rising sovereignty requirements into a repeatable, differentiated practice with Microsoft Sovereign Cloud and the Digital Sovereignty specialization. Customers across industries, especially in government and regulated sectors, are raising sovereignty earlier in the buying cycle, often before a platform is chosen. Questions about data residency, operator access, encryption, resilience, and where AI workloads run are increasingly part of the first architecture conversation. As AI reshapes economies, digital sovereignty has moved from an IT consideration to a business-critical priority, shaping how organizations approach cloud and AI transformation. For Microsoft partners, that shift creates an opportunity to engage earlier and more strategically. Partners can translate sovereignty requirements into architecture, deployment, and operating models that span cloud, security, data, AI, and ongoing governance. With Microsoft Sovereign Cloud , partners can address customer requirements across Sovereign Public Cloud, Sovereign Private Cloud, and the Sovereign Partner Ecosystem. Microsoft’s Digital Sovereignty specialization provides a way to validate that expertise and turn a growing customer requirement into a repeatable, differentiated practice. Why digital sovereignty is becoming a business priority At its core, digital sovereignty is the ability for organizations and governments to operate securely and independently in a global digital economy while retaining real control over their data, infrastructure, and operations. Five key scenarios are bringing these questions forward, and each calls for Microsoft controls and capabilities that strengthen digital sovereignty: Policy and governance requirements are evolving across regions, creating a need for enforceable controls that address national and industry obligations. Sovereign AI introduces new considerations around where data and AI workloads operate and how they are governed. Cloud operator access raises questions about who can reach an environment and under what conditions. Data residency and confidentiality requirements call for greater control over sensitive data, including while it is in use. Cloud resilience and business continuity require organizations to prepare for disruption while maintaining critical operations. Continue reading here

Adding persistence to the Aspire dashboard

Thu, 08 Oct 2026 17:00:00 +0000

Aspire 13.6 adds dashboard persistence and run history. Revisit telemetry after a restart, retain more data, and explore the SQLite and Dapper implementation behind it. The post Adding persistence to the Aspire dashboard appeared first on Aspire Blog .

A closer look at noise reduction in Stacks What-If

Thu, 08 Oct 2026 16:12:33 +0000

Following the general availability of what-if for Azure Deployment Stacks , this article deep dives into the co-released feature of "noise reduction", which was a top community feature ask from Deployment Stacks customers. In this article, we will cover what noise reduction solves, how it works, and how to get started with noise reduction. For the full reference, see Noise reduction in deployment stack what-if results on Microsoft Learn. The problem with Deployments What-if results What-if for deployments compares a Bicep file or ARM template against the current state of the deployed resources and reports every difference between the two. Historically, a large share of those differences are changes that won't actually happen, and they're considered noise. Noise is a difference that what-if reports but that deploying the template wouldn't actually change. It shows up when the property values declared in your template differ from the resource as it exists in Azure for reasons that have nothing to do with your edit. A resource provider fills in default values for properties you left out. It also returns read only properties that no template can declare, which surface as false deletions because nothing in your file matches them. Write only properties can add noise too, but only when what-if doesn't know that a property is write only, because the value you deploy is never returned to compare against. This has been one of the most common pieces of feedback we receive about what-if. Noise makes a result harder to trust, and a result that is not trusted is slower to act on. Review turns into a manual exercise, because someone has to read every line and dismiss the ones that nobody authored. As a stack grows to manage more resources, the problem compounds. What noise reduction looks like Here is what a regular deployment what-if response looks like: In this example, the property values of properties.sqlEndpoint and properties.minimalTlsVersion on the Cosmos DB account, sku.tier and properties.kafkaEnabled on the Event Hubs namespace, and the five properties.siteConfig values on the web app show up as changes but are actually noise (given they were not a part of the original template). Now, with Deployment Stacks What-if, the response is more accurate and the noise is removed, as shown in the following example. Where the noise comes from Noise most commonly comes from default properties for resource types, but it can also come from read only properties, and from write only properties that what-if doesn't recognize as write only. Below are common examples of such noise: Resource type Property reported as changed Why it appears Cosmos DB account properties.sqlEndpoint Server generated, read only Cosmos DB account properties.minimalTlsVersion Provider default applied after deployment Event Hubs namespace sku.tier Derived from sku.name by the provider Container app properties.runningStatus Runtime state rather than configuration Role assignment properties.principalType Resolved by the provider at creation Stream Analytics job properties.runtimeMode Provider default applied after deployment The same pattern holds as the resource types vary. On a separate stack managing 13 resources spanning storage, networking, Event Hubs, Container Registry, App Service, Log Analytics, and Application Insights, what-if for deployments returned 30 property level differences on an unedited template. Stacks What-if against the same stack returned none. How Deployment Stacks filter noise A Deployment Stack keeps a record that a standalone deployment does not. It captures the noise that was already present after the last successful deployment of that stack. After each successful stack deployment or update, Azure runs what-if and saves the result as a baseline. That baseline captures the differences that come from Azure itself, such as provider defaults, rather than from any later edit you make to the template. The next time you run Stacks What-if, Azure compares the new result against that baseline. If a property looks the same in both, Azure drops it from the output, because the edit you are previewing is not what introduced that difference. Noise reduction is enabled in all regions and there is no flag to set. It depends on a baseline, so it applies to stacks that were deployed or updated on or after August 13, 2026. If a stack hasn't been deployed since then, deploy or update it once to record a baseline. The next Stacks What-if run uses that baseline. If a result looks noisier than you expect, check when the stack was last deployed, because a missing baseline is the most common cause. What noise reduction does not hide Filtering against a baseline removes differences that were already present when the baseline was recorded, not differences that appear afterwards. In a test stack, an Azure Policy assignment added a myTag tag to every managed resource at deployment time. What-if for deployments reported tags.myTag as a deletion on all four resources, because nothing in the template declared it. Stacks What-if reported those same four resources as NoChange, because the tag was already in the baseline. Adding a different tag directly to one of those resources after the stack had deployed produced the opposite outcome. That tag was not in the baseline, so Stacks What-if reported it. Drift introduced after a deployment still surfaces. Getting started The quickest way to evaluate this is against a stack you already have. Run Stacks What-if with the unchanged template and compare the result to what what-if for deployments reports for the same file. Unlike a deployment what-if, a Stacks What-If Result is itself an Azure resource , so the name you give it, noise-check in the examples below, becomes the resource name you use to retrieve that result later: Azure PowerShell: New-AzResourceGroupDeploymentStackWhatIfResult ` -Name "noise-check" ` -ResourceGroupName "my-rg" ` -StackResourceId "" ` -TemplateFile "main.bicep" ` -ActionOnUnmanage DetachAll ` -DenySettingsMode None ` -RetentionInterval "PT3H" Azure CLI: az stack-whatif group create \ --name "noise-check" \ --resource-group "my-rg" \ --stack-id "" \ --template-file "main.bicep" \ --action-on-unmanage "detachAll" \ --deny-settings-mode "none" \ --retention-interval "PT3H" Keep in mind that --action-on-unmanage and --deny-settings-mode affect the Stacks What-if result, because they change how the stack would manage your resources. The clearest way to see this is to remove a resource from your template and run the same evaluation twice. With detachAll, that resource is reported as v Detach and its management status moves from managed to notManaged, but it stays in Azure. With deleteResources, the same resource is reported as - Delete and is listed again under Resources Marked for Deletion. The template change is identical in both runs, so the difference in the result comes entirely from actionOnUnmanage. Running Stacks What-if does not change any deployed resource. It does create one resource, the Stacks What-If Result itself, which is how the output is stored so you can retrieve it later. Stacks What-if is available at resource group, subscription, and management group scope, in Azure CLI, Azure PowerShell, and the Azure SDKs. Azure PowerShell takes PascalCase enum values such as DetachAll and None, written without quotes. Azure CLI documents the camelCase spellings detachAll and none. Use the spelling each tool documents, and if a value is not recognized the error lists the allowed values. The retention interval sets how long Azure keeps the result before cleaning it up. It currently accepts ISO 8601 durations between PT1H and PT3H, so the PT3H used in these examples is the longest window available today. If you intend to hand a result to a reviewer as an approval artifact, plan around that window, because the result is removed once it expires. The result is printed in up to three sections. Changes to Stack covers the stack resource itself, such as deny settings, and appears when those change or when the stack does not exist yet. Changes to Managed Resources lists every managed resource with its change type and property level detail. Resources Marked for Deletion repeats, as an explicit list with a count, the resources the run predicts will be deleted, which is the section to read first when you are reviewing a risky update. You need permission to read the deployment stack and the resources it manages, and permission to create the result. The operations involved are Microsoft.Resources/deploymentStacks/read, Microsoft.Resources/deploymentStacksWhatIfResults/write to create a result, Microsoft.Resources/deploymentStacksWhatIfResults/read to retrieve one, and Microsoft.Resources/deploymentStacksWhatIfResults/delete to remove one. Because the evaluation compares your template against live resource state, the identity running it also needs read access to the managed resources themselves. Tell us what you think If Stacks What-if reports a property you did not change, open an issue in Azure/deployment-stacks and include the resource type, the full property path as it appears in the output, and the correlation ID. Because the result is a stored resource rather than terminal output, the correlation ID is saved on it and can be read back at any time with az stack-whatif group show --name --resource-group --query properties.correlationId , or from the CorrelationId property returned by Get-AzResourceGroupDeploymentStackWhatIfResult . Resources Noise reduction in deployment stack what-if results . The Microsoft Learn article on noise reduction, covering where noise comes from, how the baseline works, and what it doesn't filter. Preview deployment stack changes with what-if . Change types, running Stacks What-if at each scope, retrieving and deleting Stacks What-If Resources, and noise reduction. Create and deploy Azure deployment stacks in Bicep . The main Deployment Stacks article, including actionOnUnmanage. Preview Bicep deployment changes by using what-if . What-if for deployments, included for comparison. az stack-whatif command reference . The Azure CLI command group for Stacks What-if at resource group, subscription, and management group scope. New-AzResourceGroupDeploymentStackWhatIfResult . The Azure PowerShell cmdlet reference, including the subscription and management group equivalents. Deployment stacks what-if results REST API . The Microsoft.Resources/deploymentStacksWhatIfResults reference, which is the contract the SDKs are generated from.

Prepare for Windows Update certificate rotation in 2027

Thu, 08 Oct 2026 16:12:27 +0000

It's time to update your devices to ensure connectivity to Windows Update moving forward. Windows Update uses certificate-based trust to confirm that your devices are connecting to authoritative Windows Update servers, so that you can have confidence in the update content delivered to your devices. As a standard security practice, these certificates have an expiration date. This means that they eventually need to be rotated (that is, replaced by new certificates). A set of these certificates will expire on May 17, 2027 and June 19, 2027 . While Microsoft is delivering solutions for most devices through normal monthly updates, some Windows versions will need IT action. If unaddressed, affected devices will stop connecting and receiving all types of updates from Windows Update. However, the key to getting updates from Windows Update beyond 2027 is to keep your devices up to date today. Note: This doesn't apply to devices receiving updates from Windows Server Update Services (WSUS). Identify and prepare devices that require action Our goal is to accomplish this certificate rotation with minimal impact to your organization. In most cases, no action is required. That's your case if your devices are running an in-support version of Windows and are up to date with recent monthly quality updates. For older or out-of-date Windows versions, however, take action as recommended in the table and described below. Windows version Action required Windows 11, version 25H2 and later None. Windows 11, version 24H2 and Windows Server 2025 Install the September 2025 Windows security update or later before June 19, 2027 . Other Windows 11 versions in support and Windows Server 2022 Install the July 2026 Windows security update or later before June 19, 2027 . Windows 10 versions in support Install the July 2026 Windows security update or later before June 19, 2027 . Long-Term Servicing Branch (LTSB)/Long-Term Servicing Channel (LTSC) releases of Windows 10 Enterprise 2019 LTSC, Windows Server 2019, and Windows Server 2016 Install the July 2026 Windows security update or later before May 17, 2027 . Other Windows versions Upgrade these devices to a supported version of Windows for client or server . Because these devices are out of support, they'll lose access to Windows Update services. To find and access release notes for your versions of Windows, browse Windows release health . What happens after the expiration date Devices on supported and updated versions of Windows These devices continue receiving updates without interruption. They already have the necessary updated certificates. Devices on supported versions of Windows that aren't up to date After the May and June 2027 certificate expiration dates, these devices won't be able access Windows Update services. Reference the table above to install the appropriate Windows security update or later depending on your OS version. These updates contain the new certificates. Use Microsoft Update Catalog to directly download and install required updates on these devices. Alternatively, distribute them via your regular management tools. Devices on unsupported versions of Windows These devices will lose access to Windows Update services and won't receive any updates as a result. We recommend upgrading to a supported version of Windows client or server . Recommended action plan for IT admins If your organization has devices that require action, here's your action plan: Identify devices running older or unsupported versions of Windows. Keep supported devices current with monthly Windows updates. Create an upgrade plan for unsupported devices before May and June 2027. Start today for early readiness Keep supported Windows devices current for a smooth certificate rotation. Doing this today has the following benefits beyond June 2027: Avoid update disruptions. Reduce security and compliance risk. Minimize last-minute remediation. Use the timeline to align upgrade, servicing, and lifecycle planning. And if you do need to act on older device populations, there's still time! Review, update, and plan upgrades for unsupported versions before the May 2027 or June 2027 certificate expiration dates. Have questions? Leave us a comment below or share your thoughts on our discussion board post . Securing today. Preparing for what's next. Learn more in the Windows Security book and Windows Server Security book . To stay up to date on the latest in security features and enhancements, visit the Microsoft Security site , follow the Microsoft Security Blog , or connect with Microsoft Security on LinkedIn and @MSFTSecurity .

Welcoming Logitech to the Microsoft Device Ecosystem Platform

Thu, 08 Oct 2026 14:38:31 +0000

We are delighted to welcome Logitech to the Microsoft Device Ecosystem Platform (MDEP). Logitech’s new generation of certified Microsoft Teams solutions, built directly on MDEP, brings its collaboration expertise to a growing ecosystem of partners working to make connected workplace experiences more dependable and accessible. Announced on October 8th, Logitech Rally Bar 2, Tap IP 2, and Tap Scheduler 2 are rolling out globally now. A trusted foundation for better meetings For organizations, a meeting room is part of a wider technology environment. Its devices need to support security, consistent operations, manageable deployments and ongoing servicing. MDEP offers a Microsoft-powered enterprise platform for connected and specialty devices, with integration into Microsoft identity, security and management capabilities and enterprise lifecycle practices. That common foundation gives partners room to focus on what makes their experiences distinctive. For Logitech, it supports a new generation of room solutions shaped by its expertise in video, audio and workplace design. For customers, the value is the combination: partner innovation supported by a shared enterprise approach, rather than a choice between differentiated experiences and a trusted platform. This collaboration brings together two complementary commitments: Logitech’s focus on the experience of people using workplace technology and Microsoft’s focus on the enterprise platform beneath it. Our shared opportunity is to help organizations build collaboration environments they can trust and evolve. Great meeting experiences should be simple for employees and dependable for IT. Building our next-generation solutions on MDEP lets us focus on the video, audio, and intuitive design customers expect from Logitech, backed by Microsoft’s enterprise platform. It’s a natural next step in our collaboration and a shared commitment to making meeting spaces work better for everyone . Henry Levak, VP & General Manager (Team Workspace Solutions Business Group) Welcoming Logitech to MDEP is about giving customers more choice without adding complexity. MDEP provides a trusted enterprise foundation so partners like Logitech can focus on what makes their devices distinctive. Together, we’re bringing that approach to meeting spaces, combining Logitech’s collaboration experiences with the security, manageability, and consistency organizations need at scale . Juha Kuosmanen, GM, Microsoft Device Ecosystem Platform Growing the ecosystem together Logitech’s arrival adds new choices to the MDEP ecosystem and reinforces the role of a shared platform in enabling partner innovation. As that ecosystem grows, our focus remains on customers: giving organizations access to differentiated devices while strengthening the foundation that supports them across their lifecycle. We look forward to working with Logitech and our broader partner community to advance dependable workplace collaboration. Explore MDEP at https://aka.ms/mdepblog and learn about the platform at https://aka.ms/mdep . For more on Logitech’s lineup, see Introducing Logitech’s Next-Gen Teams Rooms Solutions Built on the Microsoft Device Ecosystem Platform .

New Wiki Editor Experience

Thu, 08 Oct 2026 14:24:03 +0000

We are excited to announce a new editing experience for Wiki pages. We are replacing the existing editor with a new editor built on Monaco Editor, the same editor technology that powers Visual Studio Code. Monaco brings many of the editing capabilities familiar to Visual Studio Code to Wiki pages, while preserving the functionality of […] The post New Wiki Editor Experience appeared first on Azure DevOps Blog .

Announcing: Multiparty private offers in Microsoft Marketplace expands to Hong Kong

Thu, 08 Oct 2026 14:17:44 +0000

Multiparty private offers give Microsoft partners a way to procure third-party cloud and AI solutions for customers through Marketplace. Software companies can expand into new markets by working with partners that bring established customer relationships,

Pre-authenticated (tempauth) URLs are retiring: move to Microsoft Entra ID tokens before April 1, 2027

Thu, 08 Oct 2026 13:10:46 +0000

Starting April 1, 2027, affected Microsoft Graph file APIs will no longer return pre-authenticated URLs. Applications using these APIs must authenticate requests with Microsoft Entra ID access tokens. The post Pre-authenticated (tempauth) URLs are retiring: move to Microsoft Entra ID tokens before April 1, 2027 appeared first on Microsoft 365 Developer Blog .

When the Answer Isn’t in the Document: Metadata-Aware Agentic RAG with Foundry IQ

Thu, 08 Oct 2026 13:00:00 +0000

The problem SharePoint libraries often contain years of carefully curated metadata, including root cause, severity, business unit, document type, owner and classification. If that metadata never reaches the retrieval pipeline, however, a RAG system cannot use it. This creates a common blind spot: the information that explains what a document is about may exist in its metadata rather than its text. Consider an incident review containing this statement: “Investigation found that a DNS record was repointed during a migration while the old target was still serving writes.” The associated Root Cause Category is Configuration change , but those words do not appear in the document. Another review might mention that a configuration change was suspected and ruled out. Text-only retrieval can therefore favour the wrong document. In the sample dataset used for this project, none of the 19 reviews classified as configuration-change incidents contained the word “configuration”, while six reviews with other root causes did. Metadata does not improve every search. It helps when the information that determines what a document is lives outside the document text. Why tuning alone cannot fix it With a native SharePoint knowledge source, document text is extracted, chunked and embedded, while standard properties are retained. Custom SharePoint columns are not part of that ingestion path. Fields such as Root Cause Category, Contributing Factors, Detection Method and Severity therefore never become structured fields available to retrieval. If the metadata is absent from the index, search tuning cannot make it count. Flattening all metadata into a single text string is also problematic: Notification Service | Sev2 | Configuration change | Missing runbook This preserves the words but loses their meaning. A root cause, severity and contributing factor represent different concepts and should remain separate fields. Bring a custom Azure AI Search index The approach is to create and control a custom Azure AI Search index, then expose it to Foundry IQ as a searchIndex knowledge source. This combines metadata control with agentic query planning and a governed retrieval surface. Approach Metadata control Agentic planning Native SharePoint knowledge source No Yes Custom index queried directly Yes No Custom index as a knowledge source Yes Yes Architecture The key design principle is simple: every chunk carries its parent document's metadata. Figure 1. Metadata-aware retrieval architecture with Azure AI Search and Foundry IQ. The ingestion pipeline extracts a document, creates chunks, attaches document-level metadata to every chunk, generates embeddings and writes the records to Azure AI Search. Foundry IQ then uses the index as a knowledge source. Azure AI Search holds the metadata. Foundry IQ decides when to use it. Figure 2. Detailed implementation view, including the baseline and metadata-aware retrieval paths. At query time, the search service calls the configured models for vectorisation and query planning. Where key authentication is disabled, the search service's managed identity needs the required access. In the tested implementation, the Cognitive Services User role resolved HTTP 401 responses from retrieve requests. Put metadata on every chunk A chunk can only be retrieved and ranked using information available on that chunk. Each metadata property should therefore remain in its own field: { "id": "doc1035-000", "parentId": "doc1035", "title": "Notification Service: failed sign-ins", "content": "", "rootCauseCategory": "Configuration change", "contributingFactors": "Missing runbook; Change outside window", "detectionMethod": "Customer report", "severity": "Sev2" } A separate metadata index does not solve the same problem because a match against metadata in one index cannot raise the ranking of a content chunk in another. What influences retrieval Four areas matter in this design: Search fields: searchFields determine which fields generated subqueries search. Semantic configuration: prioritised fields give the semantic reranker access to important metadata. Query hints: hints help the planner connect natural-language requests to known metadata values. Filters: a baseFilter or request-level filterAddOn can enforce constraints. Boost hints influence ranking without excluding documents. Filter hints can narrow the result set when the planner determines that a filter is appropriate. "queryHints": { "boosts": [{ "kind": "fieldValue", "field": "rootCauseCategory", "fieldValues": ["Configuration change", "Capacity", "Software defect", "Dependency failure", "Certificate expiry"], "boost": 3.0, "boostInstructions": "Boost when the user describes what caused an incident." }] } Hints are best effort. Hard requirements should use a base filter or document-level access control rather than relying on the planner to select a hint. The tested configuration used the 2026-08-01-preview API. Current documentation should be checked for supported models, limits and behaviour before implementation. Measuring the impact Two knowledge bases were created over the same Azure AI Search index. The baseline searched title and content. The metadata-aware configuration used the same content plus structured metadata, semantic configuration and query hints. Ten questions were run through both configurations. Correctness was determined directly from the metadata attached to returned reviews, rather than by asking an LLM whether a result appeared relevant. For the question “What can be learned from outages caused by configuration changes?” , the planner generated: rootCauseCategory eq 'Configuration change' Matching reports in top 5 Score Baseline 0 Metadata-aware 3 Best possible 5 Across ten questions and four runs using gpt-5.4-mini for query planning, the baseline returned 26 matching reviews in the top five. The metadata-aware configuration returned 39 to 41, against a best possible score of 50. The gains appeared where metadata carried the missing meaning: Configuration changes: 0 → 3 Configuration changes reported by customers: 0 → 3 Capacity in production: 1 → 5 Alert fatigue: 3 → 5 Queries whose important terms already appeared in the document text scored 5/5 in both configurations. The result is therefore more specific than “metadata improves search”: metadata closes a retrieval gap when document text does not fully describe what the document represents. A failure mode worth handling Because query planning uses an LLM, the planner can occasionally generate a filter that the search index rejects. Two invalid examples observed during testing were: severity eq Sev1 changeRelated eq true The first omitted quotes around a string. The second treated an Edm.String field containing Yes and No as a Boolean. The latter caused the retrieve request to fail with HTTP 502. The fix was to make the schema and allowed values explicit: This is a text field, not a Boolean. The only valid values are 'Yes' and 'No'. Never compare the field with true or false. Application code should also handle retrieval failures rather than assuming every generated filter will be valid. Production considerations A custom index provides control, but the solution now owns ingestion. Options include the SharePoint indexer with custom columns, an Azure Function using Microsoft Graph, or an existing pipeline built with Logic Apps, Azure Data Factory or Microsoft Fabric. A custom Azure AI Search index does not automatically inherit the SharePoint permissions model. Where users have different document permissions, ACLs must be carried into ingestion and retrieval. Query hints should also be regenerated when taxonomy values change. Key takeaways Confirm that the required metadata reaches the index. Keep metadata structured rather than flattening it into one text field. Attach parent-document metadata to every chunk. Use search fields, semantic configuration, query hints and filters deliberately. Describe field types and valid values clearly in filter instructions. Evaluate against a baseline using objective correctness rules. Metadata-aware retrieval is not about making every search better. It gives the retrieval system access to context that does not exist in the document text. Try the proof of concept The complete proof of concept, synthetic dataset, index scripts, knowledge-base configurations and A/B evaluation harness are available in the GitHub - shikha-msft/foundryiq-metadata-agentic-rag . References Create a search index knowledge source Create a knowledge base Query a knowledge base via API or MCP What is Foundry IQ?

New in Microsoft Marketplace: Offers published August 28-31, 2026

Thu, 08 Oct 2026 13:00:00 +0000

Learn about 265 new offers that went live in Microsoft Marketplace, a single destination to find, try, and buy cloud solutions, AI apps, and agents to meet your business needs. Get it now in our marketplace AB Support : AB Support is multilingual AI customer service tool for Microsoft 365 that converts web chat, email, and forms into tickets in Microsoft Teams. The AI answers using your knowledge base and forwards unresolved issues to your team. Acumens Vendor Deposits & Prepayments Management : Acumens Vendor Deposits & Prepayments Management streamlines vendor deposit workflows in Microsoft Dynamics 365 Business Central. Acumens enables flexible deposit setup, consolidates multiple purchase orders (POs), targets specific credit memos, integrates with the payment journal in Dynamics 365, tracks multi-PO drawdowns, and offers advanced accounts payable reporting, enhancing financial control and cash flow management. CampusMind Accessibility for State and Local Government : CampusMind AI offers AI-powered bulk PDF remediation for state and local governments, ensuring compliance with WCAG 2.1 AA, Section 508, and ADA Title II. Available for easy deployment as a Microsoft Azure application, CampusMind AI automates structural repair, tagging, OCR, and accessibility fixes, supports human review, integrates with workflows, and enhances document accessibility while protecting sensitive data. Certisyn Bastion : Certisyn Bastion verifies your public-facing security posture using 196 controls across 37 categories including TLS, DNS, and email authentication. Bastion provides clear grades, detailed findings, and remediation steps aligned with recognized frameworks. Certisyn Forensis : The Certisyn Forensis forensic engine authenticates files, detects tampering, screens for synthetic media, and conducts analysis, then provides sealed, verifiable reports with confidence scores. Ideal for compliance, legal, and investigative use. Checkpoint by Compliance365 : Checkpoint by Compliance365 is a compliance assessment platform for scanning your Microsoft 365 tenant against recognized security standards including ISO/IEC 27001, SOC 2, and NIST CSF. Checkpoint tracks control coverage, generates statements of applicability, and shows evidence status. CloudPilot AI - Your SRE Agent Inside Kubernetes : CloudPilot AI helps SREs and DevOps teams cut Kubernetes costs, boost application performance, and reduce operational risks. It autonomously eliminates cloud waste without manual tuning, enhancing resource efficiency and optimizing Microsoft Azure usage for global customers. CloudScrub : CloudScrub helps organizations manage Microsoft Azure costs by analyzing usage, identifying waste and security risks, and enabling controlled remediation with audit trails. CloudScrub integrates with your Azure subscriptions using Microsoft Entra ID, offers AI-assisted insights, and supports multiple plans. Coforge Managed Services for Red Hat : Coforge’s Red Hat Ansible Automation Platform Managed Services offers enterprise automation and options for consulting, implementation, governance, and support. Coforge streamlines hybrid infrastructure management, enhances compliance, and reduces manual tasks. Ideal for IT teams scaling automation, it ensures operational consistency, governance, and efficient infrastructure management across complex environments. Coherent Spark for Insurance : Coherent Spark transforms Microsoft Excel-based insurance rating models into secure, high-performance REST APIs without rewriting code. It accelerates updates, preserves actuarial control, ensures IT governance, and provides audit trails. Trusted by over 150 institutions, Coherent Spark enhances model transparency, reduces risk, and integrates seamlessly into underwriting and policy systems. Expenditure Management App : The Expenditure Management App by DK Consulting Ltd streamlines financial control for small and medium-sized businesses by providing cloud-based invoice submission, automated approval workflows, and payment tracking. Expenditure Management, built on Microsoft Power Apps, reduces paperwork, speeds approvals, ensures compliance, and offers centralized document storage and real-time spending visibility, enhancing efficiency and audit readiness for growing businesses. Extension Auditor Browser Security Platform : Extension Auditor secures managed Microsoft Edge, Google Chrome, and Brave Software Brave browsers by discovering, assessing, enforcing policies, monitoring changes, and providing audit evidence for browser extensions. Extension Auditor can be managed from Microsoft Entra and other consoles to aid IT teams in managing extension risks without proxies or new agents. FinOps Pilot for Microsoft Azure : FinOps Pilot for Microsoft Azure offers multi-tenant, read-only cost visibility via Microsoft Cost Management API. FinOps Pilot provides dashboards, KPIs, anomaly detection, cost allocation, and FinOps action plans. It ensures secure, easy onboarding with Microsoft Azure Lighthouse, enabling efficient Azure spending management and reporting. FlyFTP : FlyFTP is a Microsoft Azure-based file-transfer app supporting systems using FTPS and SFTP protocols. FlyFTP offers per-user isolation, managed TLS, static IP, and client allow lists. Ideal for B2B file exchange, it simplifies administration and ensures resilient transfers within your Azure subscription. Indian Tax API : Indian Tax API for Microsoft Dynamics Business Central adds India GST fields to standard APIs, enabling seamless integration with e-commerce, logistics, and point-of-sale systems. The API supports master data, documents, and actions with GST compliance. Legal CRM Integration with Microsoft Dynamics 365 Business Central : BC4Legal enhances Microsoft Dynamics 365 Business Central for law firms by providing legal financial management, matter-centric accounting, billing, trust accounting, procurement, and analytics. It integrates with Microsoft 365 to support client and matter lifecycle management, improving financial control, profitability tracking, and streamlined legal practice operations. Meeting Angelo : Meeting Angelo integrates with Microsoft Teams to provide automatic AI-generated meeting summaries, highlighting key decisions and action items. It requires minimal permissions, works with Teams transcription, and offers a personal dashboard and live in-meeting tracking. Advanced features include transcript analysis and CRM integration. Mindline Security Reporting : Mindline Security Reporting delivers scheduled, plain-language Microsoft 365 audit summaries via email, tracking sensitive actions like label downgrades and multi-factor authentication registrations. It stores data securely in your Microsoft Azure subscription and aids compliance teams by providing readable, retained records. Multi-Cloud : Snowflake provides a fully managed, enterprise-ready platform unifying data with native integrations. Snowflake enables seamless collaboration, AI integration, and analytics without complex infrastructure. It reduces costs, ensures security, supports scalable growth, and offers transparent, consumption-based pricing that lets businesses embed AI in workflows and confidently manage their data estate. Omni Redact : Omni Redact streamlines sensitive media review with AI-assisted identification, human oversight, and a unified workflow. It supports video/audio redaction, transcript editing, case management, and controlled sharing. Omni Redact's security features include password protection and watermarks, ensuring efficient, accurate redaction and secure content export with full audit traceability. Pacer Production Scheduler : Pacer Production Scheduler enhances Microsoft Dynamics 365 Business Central for small and mid-sized manufacturers by providing finite capacity scheduling, AI-powered assistance, and real-time replanning. It optimizes production sequencing, respects constraints, and offers an interactive Gantt chart, enabling efficient shop floor management without complex integrations or external systems. PlaTT Container Portal : Available only in Japanese, the PlaTT developer portal provides preconfigured container images for Microsoft Azure Kubernetes Server to enhance development productivity for DevOps teams. PlaTT facilitates smooth deployment and implementation of container images as well as delivering ongoing operational support and version upgrades. QpiAI Agent Hive Flat : QpiAI Agent Hive is an enterprise multi-agent orchestration platform that fine-tunes AI agents using your data, running securely on Microsoft Azure, VPC, or on premises. It offers visual workflow building, intelligent model routing, persistent memory, and human-in-the-loop governance, delivering domain-fluent, cost-effective AI agents with full traceability and compliance. Read & Confirm: Policy Attestation : This policy management tool automates reminders, escalations, and annual recertifications by integrating with Microsoft Teams and SharePoint for easy confirmations. Read & Confirm includes a live compliance dashboard and one-click exports of audit data to CSV files. Revve AI - AI Customer Engagement Platform : Revve is an AI-powered contact center platform offering voice and chat agents, ticketing, and unified messaging across channels. Revve automates the majority of routine support, supports TCPA-compliant outbound campaigns, and deploys on Microsoft Azure or on-premises. RIOT - Risk, Issue & Opportunity Tool : RIOT is a project governance tool built for SharePoint Online to help organizations manage risks, issues, and opportunities with PMBOK-aligned processes. RIOT features multi-dimensional impact assessment, interactive dashboards, role-based access, automated email alerts, and FedRAMP/NIST 800-53 security controls. Sentaro: AI Behavioral Defense for Microsoft 365 : Sentaro enhances Microsoft 365 security by detecting AI-driven phishing, business email compromise, and impersonation using in-house AI models. Sentaro integrates via Microsoft Graph API without disrupting mail flow, labeling threats in Outlook. Additional layers monitor software-as-a-service apps, domain credentials, and user behavior, ensuring GDPR-compliant, EU-hosted protection for regulated teams. SkyLine G3 Production Module : The SkyLine Production add-in extends Microsoft Azure-hosted Response ERP and SkyLine Core with cloud-based work order management, tracking, costing, and reporting. Features include work order creation, stage tracking, component substitution, and lot/serial number tracking. It integrates with bill of materials, inventory, and sales modules. SmartVisuals Gantt Chart : SmartVisuals Gantt Chart enhances Microsoft Power BI with project-tracking features including collapsible task hierarchies, dependency arrows, critical path highlighting, and baseline comparisons. The chart runs fully locally without external data sharing. Add-on features include dependencies, critical path, and grid columns. Ideal for managing diverse project timelines securely. SmartVisuals Radar Chart : This customizable radar chart for Microsoft Power BI provides fixed scales, multiple series, and extensive styling. Additional features are available, including advanced analytics, normalization, inverted axes, targets, and conditional formatting. SolasOS : SolasOS provides workplace intelligence from Microsoft 365, processed entirely within your Microsoft Azure tenant, giving your employees private insights into their work and collaboration. Your organization receives anonymized, real-time reports on engagement, workload, and change impact. SolasOS ensures data privacy and supports ISO standards. SPC Variable Chart (Pro) : PBIVizEdit's SPC Variable Chart (Pro) offers Xbar-R, Xbar-S, and I-MR charts, allowing you to monitor process mean, range, and variation. Features include customizable control limits, rule-based violation highlights, and flexible embedding in Microsoft Power BI, SharePoint, and apps. Veryation Org Chart & Directory : Org Chart & Directory from Veryation transforms Microsoft Entra data into a searchable directory and interactive org chart within Microsoft Teams. Features include search by name, title, or skill, expandable reporting lines, admin overrides, profile photos, and contact details. Virtual Fields : Virtual Fields enables no-code creation of custom, calculated fields across tables within Microsoft Dynamics 365 Business Central. The add-in supports manual entry, dynamic calculations, and cross-company lookups. Thanks to seamless integration, Virtual Fields lets users extend Dynamics 365 Business Central quickly, reducing development effort and enhancing business insights and flexibility. VSDEL - SysML v2 Workspace : VSDEL is a web-based Systems Modeling Language (SysML) v2 workspace enabling full model-based systems engineer in-browser without installations. VSDEL supports all standard views, Git-style collaboration, requirements management, and AI-assisted drafting. Designed for regulated programs, it includes role-based access via Microsoft Entra. xverified Tracing & Verification Platform : xverified is a South African-built platform for tracing and verifying unclaimed benefits and debt recovery. xverified uses authoritative checks from Home Affairs and CIPC to verify identities, manage deceased estates, and recover debts. Built on Microsoft Azure, it ensures compliance, audit trails, and supports multiple programs for institutions such as funds, insurers, and law firms. Easily deploy virtual machine images FreePBX v17 on Debian 12 Chef on CentOS Stream 9 EspoCRM on Ubuntu 24.04 LTS NumPy on CentOS Stream 9 AI Demand Forecasting & Supply Chain for Logistics Apache APISIX Apache SkyWalking ArcadeDB on Ubuntu 26.04 LTS Artifact Hub Baikal Bazel Buildfarm BIRD Internet Routing Daemon CapRover checkov Chrony NTP Time Server Crawl4AI Cryptgeon Dante SOCKS Proxy Server dbt Core Defect Dojo on Ubuntu 26.04 LTS ejabberd XMPP Server File Browser Firecrawl Fluentd Formbricks Gatus GNS3 Server Grafana Alloy IXP Manager KitchenOwl Kopia KrakenD API Gateway LibreBooking Mastodon MetaClawPro NADA NetDisco on Ubuntu 26.04 LTS Open AI Web UI Ollama OpenAI Web UI OpenBao OpenCanary Honeypot Penpot PlantUML Server QuestDB Reposilite S3Proxy SFTPGo Sonatype Nexus Repository OSS Traefik with CrowdSec Security Engine Umami UnoPim Product Information Management on Ubuntu 26.04 LTS Verdaccio on Ubuntu 26.04 LTS vLLM with WebUI Wazuh SIEM YugabyteDB Zot OCI Registry zrepl CentOS 10 Latest CentOS 10 LVM Docker CE on Ubuntu 26.04 LTS Elasticsearch on Ubuntu 26.04 LTS ELK Stack on Ubuntu 26.04 LTS LAMP on Ubuntu 26.04 LTS LEMP on Ubuntu 26.04 LTS Oracle Linux 9.5 LVM Oracle Linux 9.5 Minimal Oracle Linux 9.6 Oracle Linux 9.7 Red Hat Enterprise Linux 9.6 LVM Red Hat Enterprise Linux 9.6 Minimal Red Hat Enterprise Linux 9.7 Rocky Linux 10 Rocky Linux 10 Minimal Apache AGE BillionMail Donetick MaxKey Microsoft GraphRAG Pi-hole piSignage Server Svix wg-easy WireGuard VPN Secure Alma Linux 9.8 JFrog Suite by Bynet AlmaLinux 8 LVM on Azure AlmaLinux 10 Minimal on Azure BHIMA Hospital Information & Accounting System on Ubuntu 24.04 LTS Binner Parts Inventory on Ubuntu 24.04 LTS Blnk 0.15 on Ubuntu 24.04 LTS CentOS Stream 10 LVM on Azure Claper 3.0 on Ubuntu 24.04 LTS CMS Made Simple 2.2 on Ubuntu 24.04 LTS Continuwuity on Ubuntu 24.04 LTS Deming 2026.08 ISMS on Ubuntu 24.04 LTS Directory Lister on Ubuntu 24.04 LTS DMARC Report Viewer on Ubuntu 24.04 LTS Documize Community on Ubuntu 24.04 LTS DOMjudge 9 on Ubuntu 24.04 LTS DumbAssets on Ubuntu 24.04 LTS Engelsystem 3 on Ubuntu 24.04 LTS Evolution CMS on Ubuntu 24.04 LTS FlatPress Blog and CMS on Ubuntu 24.04 LTS Flectra 3.0 on Ubuntu 24.04 LTS Flexisip SIP Proxy on Ubuntu 24.04 LTS Formance Ledger on Ubuntu 24.04 LTS Genealogy on Ubuntu 24.04 LTS Gitea + Woodpecker CI DevOps Stack on Ubuntu 24.04 LTS GlusterFS on Ubuntu 24.04 LTS Gokapi on Ubuntu 24.04 LTS Grimmory on Ubuntu 24.04 LTS Grimoire 1.0 on Ubuntu 24.04 LTS Hockeypuck OpenPGP Keyserver on Ubuntu 24.04 LTS Immich on Ubuntu 24.04 LTS Infrahub on Ubuntu 24.04 LTS Invio on Ubuntu 24.04 LTS/a> istSOS 4 on Ubuntu 24.04 LTS Jenkins CI with SonarQube Quality Gate on Ubuntu 24.04 LTS Kitsu on Ubuntu 24.04 LTS LibreNMS and Oxidized LORIS Neuroimaging Data Platform on Ubuntu 24.04 LTS Mail-Archiver on Ubuntu 24.04 LTS MapFish Print on Ubuntu 24.04 LTS Mataroa on Ubuntu 24.04 LTS Meeds on Ubuntu 24.04 LTS MemberMatters on Ubuntu 24.04 LTS Mercator Cartography on Ubuntu 24.04 LTS Minarca Self-Hosted Backup Server on Ubuntu 24.04 LTS mongo-express 1.0.2 with FerretDB on Ubuntu 24.04 LTS MOTIS on Ubuntu 24.04 LTS NethServer 8 on Azure nfdump NetFlow Collector on Ubuntu 24.04 LTS Ontime on Ubuntu 24.04 LTS OpenSTAManager 2.10 on Ubuntu 24.04 LTS Oqtane 10 on Ubuntu 24.04 LTS Oracle Linux 7 on Azure Oracle Linux 9 Minimal on Azure Percona Server for PostgreSQL 18 PyWPS on Ubuntu 24.04 LTS Qcadoo MES on Ubuntu 24.04 LTS RAGFlow on Ubuntu 24.04 LTS Raven on Ubuntu 24.04 LTS Razzia 3.1 on Ubuntu 24.04 LTS Roadiz CMS on Ubuntu 24.04 LTS SamWaf on Ubuntu 24.04 LTS Tenzir on Ubuntu 24.04 LTS Tracktor on Ubuntu 24.04 LTS uMap on Ubuntu 24.04 LTS/a> uPortal 5 on Ubuntu 24.04 LTS Veloren Server Ubuntu 24.04 LTS VoucherVault on Ubuntu 24.04 LTS WBCE CMS 1.6 on Ubuntu 24.04 LTS WeddingShare on Ubuntu 24.04 LTS Yuvomi on Ubuntu 24.04 LTS Zen Notes on Ubuntu 24.04 LTS ZenTao Project Management on Ubuntu 24.04 LTS Databricks OLAP Analysis Rocky Linux 9 Gen2 Rocky Linux 9 Latest Rocky Linux 9 LVM Rocky Linux 9.8 Gen2 Rocky Linux 9.8 LVM Database with PostgreSQL 18 on Oracle Enterprise Linux 8 Database with PostgreSQL 18 on Oracle Enterprise Linux 9 Database with PostgreSQL 18 on Oracle Enterprise Linux 10 Go further with workshops, proofs of concept, and implementations Agent in Production: 4-Week Proof of Concept : CG Tech builds a custom Microsoft Copilot Studio agent to automate a high-value task within your existing Microsoft 365 environment. This offer includes design, governance, integration, testing, and handover, enabling your team to extend agents safely. Ideal for organizations seeking efficient, compliant AI task automation. Application Modernization: 3-Month Implementation : ELEKS's service will transform your legacy systems into secure, scalable cloud-native solutions built on Microsoft Azure. Benefits include reduced costs, improved performance, faster delivery, enhanced security, and AI support. Services cover assessment, strategy, migration, testing, and documentation, enabling reliable, maintainable, and innovative applications. Application Modernization: 6-Month Implementation : ELEKS modernizes legacy systems by transforming them into secure, scalable, cloud-native solutions on Microsoft Azure. This service includes application re-hosting, re-platforming, refactoring, CI/CD, testing, and deployment. Using an incremental approach, ELEKS ensures business continuity, reduces risks, and delivers architecture, code, pipelines, and documentation for seamless migration. Azure Synapse to Microsoft Fabric: Migration : Cyclotron streamlines transitioning from Microsoft Azure Synapse to Microsoft Fabric, offering assessment, migration, and optimization services. It simplifies data platforms, reduces costs, enhances governance, and accelerates AI-driven insights. The solution ensures seamless migration, performance tuning, and enables modern analytics with improved scalability and operational efficiency. Copilot Studio Agent: 2-Week Proof of Concept : CloudAtlas AI Factory and UnifyCloud help organizations quickly develop, deploy, and validate Microsoft Copilot Studio AI agents tailored to business needs. The engagement connects enterprise knowledge, automates workflows, and tests real scenarios, reducing risk and enabling scalable AI adoption within the Microsoft ecosystem. CyberOne Deployment Accelerator for Microsoft Agent 365 : CyberOne’s deployment accelerator for Microsoft Agent 365 enhances enterprise AI governance, security, and lifecycle management. CyberOne offers workshops, risk reviews, access control design, and audit guidance, helping organizations transition from unmanaged AI use to secure, compliant adoption aligned with business goals and Microsoft security technologies. DELA Supply Chain Delivery Assistant: Implementation : SoftServe's DELA is a multi-agent AI solution integrated with Microsoft Outlook and Teams, streamlining supply chain order handling. It automates email processing, predicts estimated times of arrival, prioritizes tasks, and provides live analytics. DELA boosts response speed, reduces errors, and lowers workloads for manufacturers and distributors which have complex operations. DevSquad IA : DevSquad IA from G&S helps software teams integrate GitHub Copilot and AI agents to boost productivity, code quality, and speed. The solution includes assessment, pilot, scaling, governance, and measurement phases, plus developer training and AI standards, enabling secure, scalable AI adoption throughout the software development lifecycle. Drata and Microsoft Cloud: Integration Services : IT Partner offers enterprise-grade integration of Drata with Microsoft 365 for automated compliance, security monitoring, and governance. Services include identity management, endpoint compliance, cloud auditing, workflow automation, and collaboration tools. Envisioning and Agent Pilot for Microsoft Agent 365: 3-Week Workshop : Qubix offers this program to envision, pilot, and govern AI agents using Microsoft Agent 365. The offer includes workshops, a working agent with secure access, a maturity assessment, and a prioritized use case backlog. Qubix specializes in Microsoft cloud solutions, enabling controlled AI agent adoption and management. Exobe Onboarding for Microsoft 365 Copilot : Exobe Onboarding ensures effective use of Microsoft 365 Copilot licenses by providing practical training for employees. This program fosters new work habits, boosting competence, productivity, and quality. It helps organizations realize tangible business value from their Copilot investment through time savings and improved daily operations. Genzeon Payer Intelligence Suite: Fabric IQ on Microsoft Fabric : Genzeon's Payer Intelligence Suite, powered by Microsoft Fabric IQ, unifies siloed payer data into a single intelligent layer, enabling real-time insights, fraud detection, auto prior authorization, and quality reporting. With rapid deployment, Genzeon will increase automated processing, reduce fraud investigation time, and deliver savings. Manufacturing Order-to-Delivery AI Agent on Microsoft Fabric: 1-Month Proof of Value : Eide Bailly will build a Microsoft Fabric data foundation and Copilot Studio agent in Teams, providing real-time order status and risk insights. Ideal for mid-market manufacturers, this solution delivers trustworthy answers, ROI analysis, and a roadmap for AI production and governance using your own data. Microsoft Fabric: 4-Week Proof-of-Value : Atea's engagement will validate data platform use cases built on Microsoft Fabric and Azure. This offer includes workshops, a working Fabric pipeline, a Microsoft Power BI report, and roadmap architecture. Designed for organizations with fragmented reporting, this engagement provides clear business insights, reduced complexity, and a scalable Fabric strategy. Microsoft Intune: Implementation : Japan Business Systems (JBS) will implement Microsoft Intune for customers who already hold Microsoft 365 E3 and E5 licenses to enable the use of remote help, endpoint privilege management, and cloud PKI. JBS will ensure design quality, reduce risk, and enable construction and testing to be completed rapidly. This offer is available only in Japanese. Orian AI Suite : Orian AI Suite by Xoriant offers enterprise AI tools, frameworks, and industry solutions to accelerate AI initiatives. Xoriant's solution supports Microsoft Azure integration, enhances decision-making, automates workflows, and improves productivity across sectors. The suite includes business solutions, engineering accelerators, and AI system foundations for scalable, governed AI deployments. Process Automation Design Sprint: 2-Week Proof of Concept : CG Tech's engagement automates manual business processes using Microsoft Power Automate, Power Apps, and either SharePoint or Dataverse within your tenant. It includes process mapping, design, building, testing, and handover. Ideal for approvals, onboarding, and reporting, this engagement improves efficiency without shifting effort. Vanta and Microsoft 365: Integration Services : IT Partner offers enterprise-grade integration of Vanta with Microsoft 365 for automated compliance, security monitoring, and trust management. Services include identity management, device security, continuous compliance, workflow automation, and collaboration tools. The implementation enhances operational efficiency and reduces risk. Contact our partners AD merchantCENTRAL Trading Adroit Scale Bridge for Aptean Advanza Marketing Automation Platform AI and Automation Opportunity: 1-Hour Briefing AI Guardian: Enterprise AI Governance AI Guardrails and Agent Governance: 3-Week Assessment ALIANDO OkTicket Connector Application Modernization for Azure: Assessment Atos AI Autonomous DLC Audit management BizPlex blaZop: AI-Native Autonomous Operations Platform Can Fabric Help Me: 3-Week Assessment Care and Community Services AI Agent: 2-Week Assessment Collect AI Application Council Process and Records Automation: 3-Week Assessment Cura Agentic Workforce Platform for Governed AI Operations on Microsoft 365 and Azure Cyber Basic Security Operation Data & AI Modernization for Azure: Assessment Delvo Labs: Engineering Studio & Consulting Document Report Preview Dynamics 365 Supply Chain Management: Assessment File Management for SharePoint FindIT ForecastGuard for Salesforce Data Quality - Performance Benchmark on Azure Fusion5 Purchase Accruals Governance Maturity Model Infrastructure Migration & Modernization for Azure: Assessment Intellify's Enterprise BI Rationalization Framework Kevra Identity for Keycloak Kevra Infra for Terrakube Kevra Security for Prowler Latitude for LinkedIn Master Data Sync Microsoft Agent 365: Readiness Assessment Microsoft Dynamics 365 Business Central: Readiness and Fit Assessment Posted Dated Check Management Rejea Pulse rocket365 Reports SharpFleet SKUDONET Load Balancer Enterprise Edition v10 SpamBlaster SYNCDATE Team Sync Testologics Waiter Now Waste Proof Whenn Worksnip This content was generated by Microsoft Azure OpenAI, then revised by human editors.

Azure Key Vault and BYOK: Lessons Learned

Thu, 08 Oct 2026 12:41:54 +0000

Bring Your Own Key (BYOK) lets you import externally generated key material into Azure Key Vault. Importing that material again creates a new version; it does not recreate the original version identifier. If Azure Storage still requires the original customer-managed key (CMK) version to unwrap (decrypt) its account encryption key, re-importing the same material under a new version does not restore that access. With Azure Storage CMK , the key in Key Vault wraps the account encryption key . A key change requires access to the current CMK version to unwrap the account encryption key before it can be wrapped with the new key . If the required version cannot be recovered at the referenced endpoint, importing the material under a new URI does not complete the transition. Keep both the key material and the required Key Vault versions recoverable. Re-importing the material alone cannot complete a recovery operation that requires the original version. The backup and restore procedures below apply to Azure Key Vault, not Azure Key Vault Managed HSM. BYOK re-import vs. key restore A versioned key URI includes the vault endpoint, key name and version identifier. Importing a key under an existing name creates a new version. Restoring a Key Vault key backup preserves the name and the version identifiers captured in that backup. These operations are not interchangeable, even when the imported material is identical. Restoring to another vault preserves the saved version identifiers but changes the vault endpoint and therefore the full URI. A service that still needs the original URI may be unable to switch to the restored copy. Account for the original endpoint, access permissions and service configuration when planning recovery. Record each versioned key URI together with its dependent workloads, access identities and owner. This inventory is needed when rotating a shared key, changing vaults or recovering from a deletion. Retain the external key material and any Key Vault object backups required by the recovery policy. If a dependent service references a key version that is no longer available, work in this order: Check whether the key or the vault is soft-deleted. If it is, recover it; recovery brings back the original identifiers. Otherwise, restore the most recent Key Vault backup that contains the referenced version into the original vault. If neither is possible, open a Microsoft support case before you import replacement material or change the service's key configuration. Key rotation in Azure Storage Creating a new version in Key Vault does not immediately change every dependent service. Azure Storage must start using the new key version before the previous version is disabled. Keep the old and new versions enabled and accessible while the change completes. Storage updates the protection of its root encryption key without re-encrypting the stored data. When automatic version updates are configured, Storage checks for a new version daily. Microsoft recommends waiting 24 hours after rotation before disabling the previous version. If the account is pinned to a specific version, update the configured version explicitly. Confirm the version in use and test data access before disabling the previous version; elapsed time alone is not sufficient. If new keys must originate in your HSM, generate the material there and import it through the supported BYOK process. Re-importing unchanged material creates a version, but does not constitute cryptographic key rotation. Key Vault auto-rotation generates new material in Azure, not in your HSM, so you cannot use it for these keys. This sequence assumes that the account is pinned to a key version, so the switch in step 4 happens only after the backup in step 3. With automatic version updates, Storage can adopt the new version at its next daily check, possibly before the backup exists. If your policy requires a backup before use, pin the key version and update it explicitly once the backup has completed. Soft delete and purge protection Azure Storage CMK requires soft delete and purge protection. Soft delete provides a configured recovery window of 7 to 90 days, with a default of 90 days. Purge protection prevents permanent deletion before that window expires. It does not prevent the initial deletion or keep a deleted key available to the service. Monitor key deletions and failed key access, and investigate before the recovery window closes. If the required object is still soft-deleted, recover it rather than importing a replacement. A recovery procedure must include the permissions, network access and responsible owner needed to perform that operation. Monitoring and guardrails Key Vault records key operations in its AuditEvent log category. Send these logs to a Log Analytics workspace with a diagnostic setting, and alert on operations that change which keys and versions exist. AzureDiagnostics | where ResourceProvider == "MICROSOFT.KEYVAULT" | where OperationName in ("KeyDelete", "KeyPurge", "KeyRecover", "KeyImport", "KeyBackup", "KeyRestore") | project TimeGenerated, Resource, OperationName, requestUri_s, CallerIPAddress, ResultSignature | sort by TimeGenerated desc If your diagnostic setting writes to resource-specific tables, query AZKVAuditLogs instead; some column names differ. On the storage side, lost key access surfaces as HTTP 403 errors such as KeyVaultEncryptionKeyNotFound, KeyVaultVaultNotFound or KeyVaultAccessTokenCannotBeAcquired. Treat these errors as incidents , not as transient failures . Resource locks do not protect keys. A CanNotDelete lock prevents deletion of the vault resource, but locks apply only to control plane operations, and deleting a key is a data plane operation. Limit who can delete, purge, back up and restore keys, and review those assignments regularly. Retention of previous key versions Active workloads, migrations and retained data backups can require old key versions after a rotation. Determine those dependencies before setting a retirement date. Data backups may still depend on retained encryption keys. Verify which versions the service requires to restore each retained recovery point; these dependencies vary by service. Test the recovery points you must retain before retiring a key. Keep disabling and deleting as separate decisions, with an owner for each. Key Vault does not support deleting individual historical versions, so deletion is not a version-cleanup strategy. Backup scope and restore constraints A Key Vault key backup is an encrypted object snapshot, not a plaintext key export or a whole-vault backup. It can be restored only to a vault in the same Azure subscription and geography as the source vault, though not necessarily the same region. Restore brings back all captured versions, not one selected version. The original key name must be available in the destination. A snapshot does not include versions created after the backup, and restoring the key does not rebuild identities, permissions or networking. Backing up a key with more than 500 versions is not supported . Check version counts and backup completion as part of the rotation process. Where key backups are required, back up the key again after each import or rotation. If policy requires a backup before use, configure the service to use the new version only after its backup has completed. Automatic adoption can otherwise occur before the backup completes. Keep the backup accessible even when the source CMK is unavailable. Restrict backup and restore permissions and monitor their use. Disabling the original key does not disable a copy restored elsewhere. Checking the active key version The following Azure CLI commands use PowerShell line continuation. Replace the placeholders, sign in to the intended tenant and run each command separately, stopping on errors. The storage account and the key vault can be in different subscriptions. You need read, list, backup, and restore permissions, plus network access to the vault . The storage account's managed identity separately needs the get, wrapKey, and unwrapKey permissions . With Azure RBAC, the Key Vault Crypto Service Encryption User role covers these permissions. Read the account's key properties and list the available versions: az storage account show ` --subscription "" ` --resource-group "" ` --name "" ` --query "encryption.keyVaultProperties" ` --output json az keyvault key list-versions ` --subscription "" ` --vault-name "" ` --name "" ` --query "[].kid" ` --output tsv The currentVersionedKeyIdentifier property reports the version in use. An empty keyVersion means that automatic version updates are enabled; a value means that the account is pinned to that version. Do not rely only on the configured keyVersion or the newest version in Key Vault. Record the identifier before and after the change, and test application reads and writes separately . Azure Storage does not currently log key rotation in its Azure Monitor logs, so this record may be your only evidence of which version was in use. Backup and restore with Azure CLI Create a key backup with a unique file name for each snapshot: $backupFile = ".\cmk-backup-$(Get-Date -Format yyyyMMdd-HHmmss).blob" az keyvault key backup ` --subscription "" ` --vault-name "" ` --name "" ` --file $backupFile To test the restore, use an approved, isolated test vault in the same subscription and geography. The key name must not already be active or reserved by a soft-deleted object. HSM-protected keys require a compatible Premium vault. Do not delete or purge production keys to make room for a restore test. az keyvault key restore ` --subscription "" ` --vault-name "" ` --file $backupFile az keyvault key list-versions ` --subscription "" ` --vault-name "" ` --name "" ` --query "[].kid" ` --output tsv Compare the final version segment of each returned URI with the source inventory; the vault hostname will differ. These commands do not change Storage encryption. A successful test restore validates the backup, not the service recovery procedure. Test that procedure separately with a non-production workload before relying on it for production recovery. Key retirement checklist Identify all services that use the key. Avoid unnecessary key sharing across production and non-production. Verify that the backup includes the required versions and can be restored to the intended destination. Confirm the version in use, test data access, and validate the required backup restores. Disable the old version only after confirming that no active workload or required backup restore still needs it. Reliable recovery requires the key material, the referenced versions and a tested service recovery procedure. When a recovery operation depends on the original CMK version, re-importing the material under a new version cannot replace it. Disable old versions only after you verify that no remaining workload or backup depends on them .

Azure VNET Integration Doesn’t Mean Your Resources Are Private

Thu, 08 Oct 2026 09:41:56 +0000

Most audit, design workshops, and architecture reviews have some version of the same moment. Someone points at a diagram, taps the App Service box, and says “that’s fine, it’s got VNet integration.” The box gets a tick, the review moves on, and 6 months later a pen test (normally driven by a security incident that … Continue reading "Azure VNET Integration Doesn’t Mean Your Resources Are Private"

💲Announcing Free Grant and Pricing for Logic Apps Automation

Thu, 08 Oct 2026 08:03:09 +0000

Today, we're announcing pricing for Azure Logic Apps Automation , now in public preview, along with monthly free grants that make it easier to start building, experimenting, and bringing automations to life. Logic Apps Automation is Azure's fully managed platform for business process automation and orchestration, including AI-powered automation. It's built for every builder with an automation problem, not just developers, and the free grants make it easy to go from idea to a working automation without a purchase decision up front. The free grant covers one managed environment per subscription and includes usage across key Logic Apps Automation capabilities, so you can start with your first use case, experiment with AI-powered automation, and run workloads in production within the included limits; then move to paid usage as your needs grow. Start today @ https://auto.azure.com/ Start free with monthly grants Every Azure subscription gets a monthly free grant across the platform. The only exception is Managed Environment which is a one-time free grant for first 60 days. When the usage stays within these limits you pay nothing. When it goes beyond these limits, you pay only for the additional usage. Usage Component Monthly free grant (per subscription) Core Platform Managed environment One environment, free for the first 60 days (2 months) Core Platform Workflow runtime 108,000 execution-seconds (about 30 hours) Core Platform Data retention 1 GB Optional Capabilities Managed connector calls 1,000 Standard + 500 Enterprise Optional Capabilities Knowledge storage 1 GB Optional Capabilities AI usage 1,100 AACs Optional Capabilities Isolated code execution 18,000 seconds (about 5 hours) What this means in practice Explore the platform, not a trimmed-down experience. The grants include workflow runtime, AI usage, knowledge, connectors, and sandboxed code, so you can explore every capability from day one. Build and iterate without watching the meter. With approximately 30 hours of execution time included each month, you can author, test, and run workflows as you build out your automation. Scale into paid usage as your needs grow. Grants reset every month, and you pay only for usage beyond them. Simple, usage-based pricing Beyond the included grants, Logic Apps Automation uses a pay-as-you-go pricing model across the capabilities your automations use. Billing has two parts: Core Platform: the managed environment, workflow runtime, and run-history retention that provide the foundation for your automations. Optional Capabilities: AI usage, knowledge storage, isolated code execution via sandbox and managed connectors, billed only when your workflows use them. For rates, regional pricing, and a worked monthly cost example, see Azure Logic Apps Automation pricing . How does the free grant works The free grant applies to the first environment you create in a subscription. Look for the Free tag next to an environment's name to see which is the free one Free environment period: The managed environment is free for 60 days, starting from the time you create it. Existing customers: If you already use Logic Apps Automation, create a new environment to use the free grant. The first new environment you create in your subscription receives it. Track your usage: In your environment, go to Settings and select the Free Grants tab to see your monthly limits and how much you've used. Important: Free grants are tied to the free environment. If you delete your free environment, you lose the ability to use the free grants, and you can't get them back by creating a new environment. Availability Logic Apps Automation is in public preview in Australia East, East Asia, North Central US, Southeast Asia, Sweden Central, UK South, and West US. Preview pricing and availability may change before general availability. Get started If you already have an Azure subscription, your included grants are available to help you start building today. Create your first Automation project, start from a template or with the AI workflow assistant, and explore what you can build with Logic Apps Automation. Get started with Logic Apps Automation Quickstart: build your first workflow Read the full pricing details MS Learn documentation Watch the Logic Apps Automation video series Share feedback or request a feature , or just let us know what you build with Automation!

Claude Haiku 5.5 is now available in Microsoft Foundry

Thu, 08 Oct 2026 00:48:21 +0000

Claude Haiku 5.5 is now available in Microsoft Foundry. The fastest and most efficient model in the Claude 5.5 family, it is built for high-volume, cost-sensitive agentic work, from live customer support to focused subtasks within larger agent systems. It also costs around 75% less than Claude Haiku 4.5 for most tasks. As teams scale AI applications, the speed and cost of each repeated task matter. Haiku 5.5 gives developers a model built for that work, helping them keep experiences responsive and delegate routine execution so more capable models can focus on complex reasoning. A fast subagent for focused work Claude Haiku 5.5 is Anthropic’s most capable Haiku model yet, with significant improvements over Haiku 4.5 across coding, tool use, computer use, and agents. Its role in the Claude family is focused execution: handling well-defined tasks quickly and efficiently as part of a broader workflow. For coding agents, a model such as Claude Opus 5.5 can plan the work and delegate specific subtasks to Haiku 5.5. These might include routing requests, summarizing context, applying small, targeted changes across many files, or checking a proposed sequence of steps. This division of work makes it practical to run more subagents in parallel while reserving deeper reasoning for the hardest problems. Responsive experiences and everyday automation Haiku 5.5 is built for interactive experiences where users expect quick answers, including voice agents, live support, and in-app assistants. It can handle straightforward customer questions and quick knowledge-base lookups as part of these applications. Behind the scenes, it supports the repeatable work that keeps business processes moving: extracting key fields from small-to-medium documents, classifying incoming content, generating summaries, and flagging items that need a closer review. Its speed and efficiency make it well suited to processing these tasks at high volume. For browser and desktop automation, Haiku 5.5 can act as a computer-use subagent for repetitive tasks such as filling forms, entering data, and moving information between applications. Support for high-resolution images also enables work with screenshots, charts, and documents. More control over cost and intelligence Haiku 5.5 is the first Haiku model with effort controls, giving teams a way to tune the balance between cost and intelligence for each task. Developers can use these controls to match the model’s effort to the demands of a workflow, with a focus on the quality and economics their application needs. Get started in Microsoft Foundry Explore Claude Haiku 5.5 in Microsoft Foundry and evaluate it on the focused tasks your application performs most often. For teams building agent systems, it adds a fast, efficient option for the repeatable work that needs to scale. Try it today claude-haiku-5-5 | Model Catalog | Microsoft Foundry

Azure App Service Community Standup: Platform Release Channels & WebSSH

Thu, 08 Oct 2026 00:00:00 +0000

Keeping an application current should not mean giving up control over testing, deployment, or troubleshooting. In the October 8 Azure App Service Community Standup: Platform Release Channels & WebSSH for Custom Containers, the team demonstrated how App Service for Linux is making those operational tasks easier, from validating runtime patches to investigating a failing backend connection.

Build bigger forms in Microsoft Access

Wed, 07 Oct 2026 23:36:12 +0000

For many years, Microsoft Access forms were limited to 22 inches in width and in the height of an individual section. That size works well for many solutions, but it can become restrictive when you are building a wide dashboard, arranging many controls, designing for a large display, or creating a detailed data entry workflow. With Big Forms, a form can be up to 2,000 inches wide, and each individual vertical dimension can be up to 2,000 inches. The combined height of all sections and their Design View section headers can be up to 2,100 inches. Continue using the familiar Access design surface, property sheet, rulers, and scrollbars, with substantially more space available when your solution needs it. More room for the solutions you already build Wider layouts Extend forms up to 2,000 inches wide for dashboards with more fields, controls, and content displayed next to each other. Taller sections Use up to 2,000 inches for an individual vertical dimension and up to 2,100 inches across all sections. Familiar design tools Enter dimensions in the property sheet or resize controls directly on the design surface as you do today. How to create a bigger form Open your object in Design View. Open an existing form, or create a new one. Resize the design surface or a section. Drag an edge beyond 22 inches, or enter a Width or Height value of up to 2,000 inches in the property sheet. Position and size your controls. Move controls into the expanded area or set larger Left, Top, Width, and Height values. Save and reopen as usual. Access preserves the expanded dimensions when you save the form. No conversion required You do not need to recreate existing forms. Open the form in a supported version of Access and extend the layout only when you need additional space. Use Big Forms from VBA You can read and set expanded dimensions through the existing VBA Properties collection. Values are expressed in twips, with 1,440 twips in one inch. The 2,000 inch maximum is 2,880,000 twips. Public Sub ResizeCustomerOverview() Const TwipsPerInch As Long = 1440 DoCmd.OpenForm "CustomerOverview", acDesign With Forms("CustomerOverview") .Properties("Width").Value = 100 * TwipsPerInch .Section(acDetail).Properties("Height").Value = 50 * TwipsPerInch .Controls("Notes").Properties("Left").Value = 24 * TwipsPerInch .Controls("Notes").Properties("Width").Value = 60 * TwipsPerInch End With DoCmd.Save acForm, "CustomerOverview" End Sub No new property names are required. Use Properties("Left") , Properties("Top") , Properties("Width") , and Properties("Height") to work with the new larger limits. Why use the Properties collection? Typed VBA members such as Control.Left retain their legacy 16 bit contract for compatibility with existing code. On an expanded form, those typed members return a value limited to the 16 bit range. The Properties collection reads and writes the complete Big Forms value. Designed with compatibility in mind Backward compatibility is determined for each form. Access only uses the new saved form format when a form actually exceeds a legacy limit. Forms that remain within the previous limits continue to use the existing format, even when they are saved by a version of Access that supports Big Forms. When a form uses the expanded range, Access saves its full values in wider properties and marks that specific form as requiring Big Forms support. An earlier version of Access can still open the database and work with its other compatible objects. If someone tries to open the expanded form, Access displays a message explaining that the form requires a newer version. Compatibility without silent data loss Earlier versions do not truncate or reinterpret an expanded form. They stop before loading that form and show a clear compatibility message, while the rest of the database remains available. Sharing a database? Make sure everyone who needs to open an expanded form is using a supported Access build. This is especially important for shared front end databases and packaged Access applications. Availability Big Forms is rolling out on Current Channel, beginning with version 16.0.20430.20146. It is enabled for some customers now and is expected to reach everyone on Current Channel early next week. If you are on that build and do not yet see the expanded limits, check again in a few days. Availability Rolling out on Current Channel Version 16.0.20430.20146 or later Platform Microsoft Access for Windows To check your version, open Access and select File > Account > About Access . Try Big Forms and tell us what you think Use the expanded design surface with your forms, then share what works well and where you would like to see improvements. Share feedback about Access Feature availability and release timing can vary by update channel.

5 reasons ESPC belongs on your November calendar

Wed, 07 Oct 2026 20:53:11 +0000

The next wave of Microsoft 365 and AI is already here. Now, it’s time to ride it at ESPC Microsoft 365 and AI Conference in Amsterdam from November 30 to December 3, 2026 . When Europe's Microsoft community, IT professionals, business leaders, developers, architects, and consultants come together for four days of ideas, innovation, and connection. It's an event you don't want to miss. Register today with code Microsoft200 to get a €200 discount on your ticket purchase. Here are five reasons to be part of the ESPC experience: 1. Get ahead of what's next in Microsoft 365, Copilot, and AI ESPC is focused on the latest innovations across Microsoft 365, AI, Copilot, Teams, SharePoint, Power Platform, Security, Fabric, Azure, and modern workplace technologies. AI has accelerated the pace of innovation like never before. This is a chance to discover what’s new and what’s next. That includes building custom AI agents, automating workflows, and connecting enterprise data that helps you keep up and get ahead. 2. Learn directly from Microsoft experts and product makers ESPC is designed to create experiences that drive productivity, innovation, and impact. You’ll gain direct access to Microsoft product leaders, engineers, and experts, and hear firsthand from the teams shaping the technologies you use every day. Join 1,800+ attendees from around the world to exchange ideas, share best practices, and learn from peers tackling similar challenges. 3. Build practical skills you can use immediately AI is everywhere. The useful part is knowing how it works for you. With 100+ expert-led sessions, 11 full-day tutorials, workshops, and hands-on learning experiences, you will leave with real-world insights, practical strategies, and solutions to use in your organization. Tutorials include topics like building reusable Power Platforms , wireframing applications using natural language, and creating your first agentic processes. And take it further with sessions that dive into areas that show you how to save time, organize content, reconfigure work, and automate business processes. There are sessions covering Copilot, agents, SharePoint, Teams, Copilot Studio, Code, Power Platform, and AI-powered work. Be sure to check out the detailed list of all the sessions and tutorials to build your ESPC learning plan. 4. Connect with the global Microsoft community The ESPC community is the real deal. It’s known worldwide for being a welcoming and community-driven atmosphere that allows you to network and build professional relationships that continue long after the event. Bring your questions, compare notes, and connect with Microsoft experts, MVPs, partners, and fellow professionals. To keep the momentum going, there are plenty of activities and chances to network. Including: Women in Tech & Allies Panel & Lunch Microsoft Most Valuable Professional (MVP) group picture Irish & UK Microsoft 365 Enthusiasts meetup Microsoft 365 in Industry meetup Women in Power Platform meetup 5. Hear from world-class speakers and keynotes We’re excited to bring together some of the most influential voices shaping the future of work, AI, and collaboration as our keynote speakers. ESPC26 Opening Keynote: The AI-Powered Enterprise by Jeff Teper, Executive Vice President, Microsoft Apps & Agents, Microsoft Leading Through Change: Fireside Conversations on AI, Productivity, and Business Transformation by Karuana Gatimu, Director of the Microsoft SCALE Experience Group, AI & Collaboration, Microsoft The Last Consultant Standing: Staying Relevant When AI Can—And Will—Do Your Job by Jussi Roine, Not Bad Security Crafting the Next Era of Work with AI and Empathy by Vesa Juvonen, Principal Product Manager, Microsoft Register today to help you stay ahead in today’s technology landscape, and don’t forget to use code Microsoft200 to get a €200 discount on your ticket purchase. These five reasons are just a start. Come find your own at ESPC Microsoft 365 and AI in Amsterdam from November 30 to December 3, 2026. It’s time to stay future-ready, drive impact, and get inspired. We’re eager to see you turn your digital workspace into a competitive advantage with Microsoft at ESPC.

Introducing the Microsoft Sentinel ASIM EmailEvent schema

Wed, 07 Oct 2026 20:21:05 +0000

Email remains one of the most common entry points for security threats. Yet email products often describe the same activity with different table names, fields, and values. This makes it harder to build detections and investigations that work consistently across data sources. The Microsoft Sentinel Advanced Security Information Model, or ASIM, EmailEvent schema is now available. It provides a common structure for email delivery and inspection events, helping customers and partners create security content that works across supported email data sources. A consistent view of email security activity EmailEvent standardizes the information analysts need to understand what happened to an email and why. It covers: Email delivery and inspection events Sender, source, and recipient information Message subject, size, direction, and delivery location URLs and file attachments SPF, DKIM, and DMARC authentication results Delivery actions such as delivered, blocked, quarantined, or deleted Threat, risk, confidence, tactic, technique, and remediation details Instead of learning a different data model for every product, analysts can query the normalized EmailEvent fields. Parser developers map each source's native data to the same schema. How it works Consider an email that contains a suspicious attachment. The email security product records the sender, recipients, attachment, authentication results, inspection verdict, and final action. A connector collects that event. A parser or Data Collection Rule maps the source fields to EmailEvent. Microsoft Sentinel can then query the normalized record using the same field names used for other supported email sources. This common structure separates security content from the details of a specific product. When another source adds an EmailEvent parser, existing source-independent queries and detections can work with that source without being rewritten around its native field names. Why it matters Simpler analytics: Write queries against one consistent set of email fields. Broader coverage: Apply source-independent security content across normalized email sources. Faster investigations: Compare delivery, authentication, attachment, URL, and threat details without translating different data models. Easier integration: Give connector and parser developers a defined contract for bringing new email telemetry into ASIM. EmailEvent does not replace the rich native data produced by email security products. It provides a consistent security layer that makes that data easier to use together. Build on EmailEvent The EmailEvent release includes the schema definition, source-independent parser framework, filtering parser, deployment templates, and validation support in the Azure-Sentinel repository. The schema version is 1.0.0. Customers can use normalized EmailEvent data to develop hunting queries, analytics rules, workbooks, and investigation experiences. Partners and community contributors can create source-specific parsers that map their email data to the schema. Get started Normalization Email Schema MS Learn Learn about normalization and ASIM Explore the EmailEvent implementation in Azure-Sentinel Deploy ASIM parsers Thank you to the ASIM engineering and partner teams who contributed to the schema, deployment path, validation, and release.

New Resource Available: Event Recap Template for Event Producers

Wed, 07 Oct 2026 20:20:45 +0000

Creating post-event content just got easier. To help Event Producers quickly share highlights, key takeaways, and community impact after their events, we've created a standardized Event Recap template for you to leverage (and/or make it your own) - it is a great way to continue to amplify and thank your speakers, sponsors and volunteers. These templates are designed to save time, ensure consistency, and make it easier to amplify the success of your event across Microsoft channels and social platforms. Simply customize the content with your event details, highlights, and resources, then publish. Whether you're recapping a CommunityDays event, workshop, meetup, or larger conference, the templates provide a great starting point for sharing your event story with attendees and the broader community. Access the templates in the MGCI Event Producer resources and use them as part of your post-event communications workflow. Thank you for helping showcase the incredible work happening across our community programs. https://aka.ms/MGCIResources - Check the Event Producers Playbook and all the templates are there. Let us know below what other templates you would like us to create and post up for download! Cheers Heather Photo from Experts Live NYC, October 2025.

Making evaluations cost-efficient

Wed, 07 Oct 2026 19:00:00 +0000

Every evaluation run is, under the hood, a stack of LLM-as-judge calls. Behind Microsoft Foundry's evaluation service, every graded row becomes judge traffic: hundreds of thousands of judge calls a day, billions of prompt tokens in any given two-week window, and roughly a dozen judge calls beneath every batch run. At that scale, the judge's token bill is a systems surface you architect, not a line item. This post is where we document our cost-efficiency initiatives as they ship. The first three attack that bill from three different angles. Restructuring judge prompts unlocked prefix caching, and on our agent-evaluation judge traffic the cached share of prompt tokens climbed from under 1% to roughly 70% on a typical day , and has held there for three weeks. TOON (Token-Oriented Object Notation) , a compact tabular serialization we adopted for rubric-evaluator verdicts, cuts judge output tokens by roughly 30% relative to JSON on the model families where we enable it. And composite evaluators score five or six evaluation rubrics in a single judge call instead of one call per evaluator, cutting input tokens by 61 to 71% and wall-clock time by 36 to 46% on the workloads we tested. Caching applies across the board; TOON applies specifically to rubric evaluators, whose verdicts are flat, uniform tables, which is exactly the shape TOON is built for (it is not a fit for deeply nested output); composite evaluators are new evaluators you can choose. Every product running evaluations on the platform inherits the first two without changing a line of code, and adopts the third by picking it. The key to why the first two levers work is that a judge call spends from three pools priced very differently. Cached input is deeply discounted: 50 to 90% off list depending on the model. Uncached input costs list price. Output is the expensive pool: output tokens list at a multiple of the input rate, typically 4 to 6 times depending on the model, and that asymmetry is industry-wide. At current list prices it holds across flagship, mid, and small tiers alike at OpenAI, Anthropic, and Google, and prefix caching itself is now offered by all three. So optimizing a judge is not "use fewer tokens". It is moving tokens into cheaper pools . The third lever is different in kind: it does not change the price of a token, it stops paying for the same tokens five or six times over. Input and output list price per million tokens, three tiers per provider. The output segment dominates every bar, which is why a 30% cut to judge output tokens matters far more than the same cut to input. Public list prices as of writing; they change. Initiative 1: Prompt caching for every judge Most of a judge prompt never changes A production judge call is lopsided. It carries a few thousand tokens of instructions, grading criteria, and few-shot examples that are byte-identical across every row of a dataset, plus a few hundred tokens of per-row data: the {{query}} , {{response}} , and {{tool_calls}} being judged. It returns a structured verdict billed entirely at output prices. Two substrate facts turn that shape into a plan. Prefix caches are prefix-match: the server reuses computation only for a leading span that is byte-identical to a prior request, usually above a minimum length and in fixed-size blocks (on Azure OpenAI, a 1,024-token minimum and 128-token blocks). Call this the static-prefix contract : everything above the first dynamic byte is cacheable; everything below it is not, no matter how static it is. And output tokens are generated serially and billed at that 4 to 6 times multiple: every token the judge writes costs you in dollars and in wall-clock. The two optimizations are corollaries. Hot prefix : arrange the prompt so that at least the minimum cacheable span of static content, 1,024 tokens on Azure OpenAI, forms the prefix. Tabular verdicts : the output is a uniform table, so stop serializing it as JSON. Put the static tokens where the cache can see them Our evaluator templates were written the way anyone writes them: instructions, then the data being judged, then the grading criteria and few-shot examples that explain scoring. Pedagogically natural, cache-hostile, and true across the whole evaluator library, not just one kind of judge. The first byte of {{query}} differs on every row, so prefix matching dies a few hundred tokens in and the static tail never caches, on any call, ever. The fix is a content-neutral reorder: Before the change, the per-row data sat second in every template, so the cache stopped matching a few hundred tokens in and the grading criteria and examples below it never cached. After the change, every static block is stacked first and the per-row data moves to the bottom, so a long byte-identical prefix is served from cache on every row and only a short dynamic suffix is processed fresh. The reorder changes byte order, not semantics. But that is a hypothesis about a position-sensitive model, so we measured score match instead of assuming it: templates were restructured with the originals frozen as controls, and the same reorder shipped to the public catalog evaluators. The pre-merge A/B: Evaluator Cache-hit gain Latency gain Score match Task adherence (agent) 82% 12% 7/7 Intent resolution (agent) 79% 16% 7/7 Groundedness 76% 5% 6/6 Retrieval quality 51% 6% 5/5 Response completeness 40% 7% 7/7 Coherence 25% 6% 6/6 Controlled-environment A/B with varying query, response, and tool-call payloads; input tokens only. Identical scores on every row, and 5 to 16% lower latency, because cached prefill is work the server never redoes. One caveat to carry forward: the larger the dynamic payload, the smaller the cached share of input tokens, so these gains vary with workload shape. In production: roughly 70% of prompt tokens now come from cache Prompt caching on agent-evaluation judge traffic, daily, over a recent month: the share of prompt tokens served from cache (blue) and the share of judge calls with at least one cache hit (orange). Nothing cached before the restructured prompts rolled out; roughly 70% of tokens and about four in five calls since. The dips fall on days dominated by unusually large dynamic payloads, not on caching regressions. Prompt caching is active and earning in production judge traffic: on agent-evaluation calls, roughly 70% of prompt tokens are served from cache on a typical day , up from nothing before the restructure rolled out, and about four in five judge calls now hit the cache. Both figures have held for three weeks. The day-to-day token share moves with workload mix: days dominated by large dynamic payloads dilute the cached share even when the prefix caches perfectly, which is why the call-level hit rate stays flat on the days the token share dips. Treat any single day as a sample, not a ceiling. The per-call anatomy shows the mechanism working exactly as designed. On a call that hits, the cache serves the large majority of the prompt, essentially the entire static prefix, and the median cached span lands on an exact multiple of the provider's 128-token cache block, day after day. Calls that miss are mostly structural: caching requires the prompt to clear the provider's minimum length, and the shortest judge calls sit near that floor. What is it worth? That depends on the model's cached-input discount, and the rates are public. At a 90% discount, a cached prompt token costs one-tenth of an uncached one, so a judge call whose prompt is 70% cached pays under 40% of its uncached input price. Current-generation models from all three major providers discount cached input by 90%; older model generations discount less, so the same hit rate is worth more on newer judge models, and caching gains grow as judges move up-tier. Cached-input discount off list price, by model. Deep discounts are the norm across providers, with older model generations discounting less. Providers differ on the write side (Anthropic prices cache writes at a premium, Google charges for cache storage), so realized savings also depend on how often a prefix is reused. Public list prices as of writing; they change. Initiative 2: TOON for rubric-evaluator verdicts The verdict is a table, so send a table The output side has no cache to exploit; the only lever is emitting fewer tokens. The mechanism is what JSON does to a uniform table under a modern tokenizer. Our rubric judge returns the same three fields, applicable, score, and reason, for every rubric dimension. Serialized as JSON, every key, quote, and brace is re-emitted per dimension, and every repetition is a completion token billed at the output multiple. Call it the pay-per-key serialization tax : JSON makes the model restate the schema once per row, at output prices. A tabular encoding states the schema once, in a header. TOON is that encoding. The same verdict both ways, tokenized with o200k_base: JSON verdict, 364 tokens pretty-printed, 310 minified: { "dimension_scores": { "factual_accuracy": { "applicable": true, "score": 5, "reason": "The definition is correct and free of hallucinated details." }, "response_completeness": { "applicable": true, "score": 3, "reason": "Covers the core question but omits practical usage guidance the user could act on." } // ... six more dimensions, identical shape ... }, "overall_reasoning": "..." } TOON verdict, 217 tokens, the full verdict: scores[8]{id | applicable | score | reason}: factual_accuracy | true | 5 | The definition is correct and free of hallucinated details. response_completeness | true | 3 | Covers the core question but omits practical usage guidance the user could act on. clarity | true | 5 | Prose is direct and well-organized; the reader can follow without effort. conciseness | true | 4 | No filler, though a bit denser than strictly necessary. tone_appropriateness | true | 5 | Neutral, professional tone throughout. actionability | true | 2 | No concrete next steps or usage patterns are provided. code_correctness | false | null | Not applicable - no code was requested or produced. example_illustrativeness | false | null | Not applicable - no examples were requested. overall_reasoning: response_completeness (3) and actionability (2) drove the verdict downward because no practical usage guidance was provided; factual accuracy and clarity are strong. Identical content: 40% fewer tokens than the pretty JSON a model naturally emits , and still 30% fewer than minified. Minification only removes whitespace; the tax is the keys. Vetting is what makes a format change shippable, so we budgeted more engineering for it than for the format . Not every model family holds a bespoke output format reliably, and falling back to a JSON-formatted retry would mean paying for the judge call twice, which defeats the purpose. So before any production traffic switched, we validated TOON end to end in our test environment, running thousands of evaluator runs across different rubric sizes and input sizes, with every input and rubric combination executed at least three times to iron out statistical noise and hallucinations. Model families that held the format 100% of the time were enabled; families that did not stay on JSON. In production, the decoder still tries TOON first and falls back to parsing JSON if a model ever ignores the instruction; the parse fallback costs nothing extra, the result is reshaped into exactly the structure the JSON path produces, and both paths pass identical strict validation. The worst case is "row scored via the JSON parse path, counter ticks", never "wrong score recorded silently". That fallback has fired zero times across every production TOON call to date, which doubles as the compliance result: the vetted models hold the format. Measured in production: roughly 30% fewer judge output tokens Savings numbers are easy to get wrong, so we measured this one conservatively. The evaluators running on TOON are not the same set as the evaluators running on JSON, and different evaluators write verdicts of different lengths, so simply comparing all TOON traffic against all JSON traffic would measure which evaluators happened to be in each group, not the format. We therefore compared the two formats three ways over more than 10,000 production runs, each way holding more constant than the last: Comparison Output tokens per call Total tokens per call Before and after, same evaluators . Each evaluator's TOON traffic after the switch against that same evaluator's JSON traffic before it, weighted by volume. This removes the "which evaluators" effect. −32% −4.6% Side by side, same weeks . TOON and JSON traffic running at the same time, limited to evaluators that appear in both groups. This also removes anything that changed over time, such as judge-model updates or traffic shifts. −28% −4.5% One evaluator, one judge model . The strictest cut: a single high-volume evaluator on a single judge model, before and after the switch, so the output format is the only thing that differs. −30% −4.3% All three land at roughly 30% fewer output tokens per judge call, with prompt tokens unchanged. As a final check, we compared JSON against itself: the same evaluators, still on JSON, before and after the rollout window. That moved by well under a tenth of a percent, which tells us nothing else in the environment shifted during the window, so the reduction belongs to TOON. Judge output tokens per call in production rubric-evaluator traffic, indexed to the JSON arm within each model family. Three of four families show a 29 to 46% reduction, including a large reasoning model. The small reasoning families (mini and nano) show no gain and do not hold the format reliably, so they stay on JSON. That is exactly why TOON enablement is a per-model-family decision made by vetting, not by model class. Output is roughly 15% of a judge call's total tokens, so a 30% output reduction is about 4 to 5% of the whole token count. But output carries the 4 to 6 times price multiple and is the serial part of the call you wait on, so the output reduction is what shows up in cost and in perceived speed. Caching's latency win is directly measured (5 to 16% in the A/B above); TOON's should track the output reduction for the same serial-decode reason, and wall-clock measurement is in progress. Initiative 3: Composite evaluators, one judge call for many evaluators Why: the same trajectory, sent once per evaluator A single agent trajectory is rarely judged on one dimension. A quality pass alone may check fluency, coherence, intent resolution, task adherence, groundedness, and task completion; a tool-use pass adds tool selection, call accuracy, input accuracy, call success, and output utilization. In a conventional pipeline each of those is its own evaluator with its own judge call, and every call receives the same messages, tool calls, tool results, and tool definitions. The shared context is paid for once per evaluator. Caching cannot help here. The trajectory is the dynamic suffix, the part of the prompt that differs on every row, so it sits below the static-prefix contract by definition. The cost grows with the number of rubrics multiplied by the size of the shared context, and long agent trajectories make that multiplication expensive. What: send the shared context once, score every rubric A composite evaluator inverts the pipeline: send the trajectory once and ask a single judge call to score several rubrics together. We built two. An Output Quality composite scores the six quality rubrics above in one call, and a Tool Use composite scores the five tool-use rubrics in one call. Each returns one score per rubric, the same shape the individual evaluators produce, so downstream thresholds, dashboards, and pass/fail logic do not change. Conventional evaluation sends the full context to each evaluator in a separate judge call. A composite evaluator sends it once and returns every rubric's score from a single call. How we validated it We compared parallel individual evaluators against one composite call per row on matched samples of single-turn agent conversations (the judge scores the final response with the full conversation history as context), one sample per workload, and repeated the runs to confirm the results were stable rather than lucky. Trajectory lengths in the samples clustered around a few thousand tokens with a long tail, and the longer the trajectory, the larger the absolute saving, exactly as the mechanism predicts. On quality, frontier judge models held stable scores across several high-value rubrics. A few rubrics proved workload-sensitive, and for those we recommend keeping a targeted individual evaluator alongside the composite. Impact: five or six calls become one Composite evaluation against one call per evaluator, per evaluated row; ranges span the quality and tool-use workloads. Per evaluated row, composite evaluation needed 5 to 6 times fewer model calls, cut input tokens by 61 to 71%, cut output tokens by 47 to 64%, and cut measured wall-clock time by 36 to 46%. Input falls because the shared context is sent once. Output falls largely because one call carries one round of reasoning and formatting overhead for six rubrics instead of six rounds, while still emitting every per-rubric verdict. Wall-clock falls because five or six serial decodes collapse into one. The results support composite evaluation as the cost-efficient default, with targeted individual evaluation reserved for the workload-sensitive rubrics. The three initiatives compose. Caching makes the static part of every judge call cheap; composite evaluation stops re-sending the dynamic part; and where a verdict is a flat table, TOON shrinks what the judge writes back. Applying this to your own judges Measure your prompt length first . Below the provider's caching minimum, restructuring is a no-op; just above it, every block of static prefix you consolidate is money. Put every static byte before the first dynamic byte . The cache stops matching at the first difference. Grading criteria and examples placed below the data being judged never cache, no matter how static they are. TOON pays for flat, uniform, multi-row output, where one header amortizes across rows. Deeply nested output and single-scalar judges have little key repetition to eliminate. Vet per model family, and keep a costless fallback . Test the format offline at scale, enable only where compliance is total, keep a parse-side fallback with identical validation, and never architect a fallback that requires a second paid call. Batch rubrics that share context. If several evaluators read the same trajectory, one composite call that scores them together removes the duplicated context, and the saving grows with trajectory length. Keep individual evaluators for the rubrics your workload is sensitive to. Validate savings with controlled comparisons, including a null check . Compare like populations, and measure your unchanged configuration against itself over the same period. If the unchanged setup moves, you are looking at drift, not savings. What's next This post will grow as further initiatives ship; each will get its own numbered section above. For the three so far, TOON already runs in every region and the composite evaluators are available to use; the frontier now is model families, coverage, and measurement. That means extending the TOON-vetted set as new judge models arrive, putting a wall-clock number on TOON's latency win, pushing the remaining short-prompt evaluators past the caching minimum, where controlled tests project cache-hit gains of 60% or more each, and extending composite evaluation to more rubric groupings as the quality checks allow. Caching is already spreading: beyond the agent-evaluation judges, the rest of the judge traffic on the same path went from nothing cached to roughly 40 to 50% of prompt tokens over the same month. From the outside, one of these changes looks like reordering text, another looks like swapping braces for pipes, and the third looks like asking one question instead of six. Shipping them safely is what took the work: weeks of controlled testing, score-fidelity checks on every changed template, thousands of vetting runs per model family, and production measurement designed so we would catch any regression before customers could. That investment lives at the platform layer, so every evaluation run on the platform inherits it: roughly 70% of agent-evaluation prompt tokens now arrive from the discounted pool, rubric-evaluator judges emit roughly 30% fewer output tokens, teams that adopt the composite evaluators send each trajectory once instead of five or six times, and nobody had to change a line of code to get the first two. The token bill arrives either way. The only question is whether you architected it. Get Started Today Start building in Microsoft Foundry: ai.azure.com Check out Build session on Foundry observability covering rubric evaluators aka.ms/build26-BRK252 Read the docs: Rubric evaluators - Microsoft Foundry | Microsoft Learn Join the community: aka.ms/ai/discord Dive deeper into the techniques covered: Composite evaluators documentation - Learn how to implement batched rubric evaluation TOON format specification - Explore the tabular serialization format

Rethinking Memory Management for Azure HorizonDB on Disaggregated Storage

Wed, 07 Oct 2026 18:53:51 +0000

In Smarter Storage for Azure HorizonDB , we described how HorizonDB moves durability, replication, checkpointing, and recovery out of PostgreSQL and into a purpose-built storage layer. The compute node writes only the write-ahead log (WAL). Data pages are rebuilt and stored by remote page servers. That design raises an obvious question: if PostgreSQL no longer reads and writes its own data files, what happens to its memory management? PostgreSQL's buffer manager was built around a specific partner: the operating system's page cache. Many of its defaults and heuristics only make sense because the kernel is quietly doing a lot of work underneath. HorizonDB removes that partner. This post explains which assumptions broke, and the changes we made to the PostgreSQL engine, so memory works well on disaggregated storage. What PostgreSQL assumes about the kernel PostgreSQL stores each table and index as ordinary files and accesses them with buffered I/O. Every page therefore can live in two places in memory: in PostgreSQL's own buffer pool (shared_buffers) and in the operating system's page cache. This "double buffering" is a deliberate part of the design, and it shapes several behaviors. A modest buffer pool. The PostgreSQL documentation suggests starting shared_buffers at about 25% of system memory. Much of the rest is expected to act as kernel file cache. A page evicted from shared_buffers is often still in the kernel cache, so reading it back costs a memory copy rather than a disk read. Prefetching is a hint to the kernel. When PostgreSQL knows it will need a page soon—during a bitmap heap scan, for example—it calls posix_fadvise with POSIX_FADV_WILLNEED. The kernel starts reading the page into its cache. A later read finds it there. PostgreSQL itself never allocates a buffer for the prefetched page. Sequential scans rely on kernel readahead. For sequential access, the kernel detects the pattern and reads ahead automatically, so PostgreSQL can issue fewer explicit hints. Ring buffers protect the cache. Large sequential scans, VACUUM, and bulk writes such as COPY use a small private ring of buffers—from a few hundred kilobytes to a few megabytes—instead of the whole buffer pool. A scan of a table much larger than memory therefore cannot push the working set out of shared_buffers. This is safe because a page that cycles through the ring is usually still in the kernel cache if it is needed again. Writes are cheap and deferred. When a dirty buffer is evicted, PostgreSQL writes it to the kernel cache, which flushes it to disk later. The background writer cleans buffers ahead of eviction so that queries rarely wait for a write. Checkpoints write all dirty pages and call fsync to make them durable. Each of these behaviors assumes that a miss in shared_buffers is usually cheap, and that writing a page means writing it to a local file. What changes in HorizonDB Figure 1. Compute memory layout: Community PostgreSQL vs. Azure HorizonDB. In HorizonDB, permanent tables and indexes do not exist as local files on the compute node. There is no kernel page cache holding database pages. A miss in shared_buffers must be served by the remote storage layer: Tier Where it lives Typical role Shared buffers Compute memory Working set; all pages are read and modified here SSD cache Compute local disk Extends shared buffers; holds cached copies of pages Page servers Remote storage fleet Page cache of the current version of every page Azure Blob Storage Remote, zone-redundant Durable backing store for pages and WAL A page that falls out of memory no longer drops into a free kernel cache. It may require a network round trip to a page server, which is much more expensive than a memory read. Writes change too. Because page servers rebuild pages from WAL, "writing" a dirty page on the compute node does not mean copying it anywhere. PostgreSQL only has to make sure the WAL describing the change is durable - a rule it already enforces before any page write. Taken together, this inverts the trade-offs behind PostgreSQL's defaults. Memory is no longer one of two caches. It is the primary cache. Design principle: shared buffers are the primary cache We organized the engine changes around one principle. shared_buffers is the primary cache, eliminating the memory overhead of double buffering and improving memory efficiency. Every page that is about to be needed should arrive in memory before the query asks for it. The following sections describe the engine changes that implement it. 1. Size shared buffers for the machine Without a kernel cache to share memory with, leaving 75% of RAM to the operating system would waste most of it. HorizonDB sizes shared_buffers automatically at 60–70% of the compute node's memory, depending on the size of the instance. The remaining memory is left for connections, query execution memory such as sorts and hashes, and the operating system. 2. Retire ring buffers Ring buffers exist so that a large scan can use a few megabytes of memory and rely on the kernel cache for anything it needs again. In HorizonDB, there is no such safety net. Recycling a small ring means that every page the scan touches is read, used once, and discarded—and a second scan of the same table must fetch everything again from storage. Ring buffers also exist to limit write traffic: a bulk operation that dirties pages in a small ring must write them out quickly. HorizonDB doesn't need to write dirty data pages back to disk at all, so that motivation disappears as well. HorizonDB therefore disables buffer ring strategies. Sequential scans, VACUUM, and bulk loads use the shared buffer pool like any other query. This is a trade-off, not a free win. A very large scan can now displace pages from shared_buffers that other queries were using. Two factors limit the cost. First, clock-sweep replacement tracks how often each buffer is used, so frequently accessed pages outlive pages a scan touched only once—and buffer replacement is an area we continue to improve. Second, pages that leave shared_buffers are not simply lost: HorizonDB can keep them close by in the local SSD cache. How it decides and what goes there is a story for a separate post. 3. Prefetch directly into shared buffers On a local disk, a prefetch miss costs a disk seek. On disaggregated storage, it costs a network round trip. Hiding that latency matters even more, so HorizonDB makes prefetching explicit, aggressive, and memory aware. Prefetch requests go to the page servers. When PostgreSQL issues a prefetch, HorizonDB sends a read request for the page to the page server that owns it, and does not wait for the answer. Each backend keeps a set of outstanding requests by default, so dozens of page reads overlap instead of running one after another. Sequential scans prefetch explicitly. PostgreSQL's read stream mechanism, which drives sequential scans and other block-range reads, normally avoids prefetching sequential blocks because it expects kernel readahead to cover them. HorizonDB turns that assumption off, so sequential reads are prefetched like any other access pattern. Responses land in their final buffer. In stock PostgreSQL, a prefetch only warms the kernel cache, so the later read still has to copy the page into shared_buffers. In HorizonDB, the page server's response goes straight into a shared buffer. When the query asks for the page, it is already in memory, with no extra copy and no second request to storage. These are only some of the prefetch optimizations we have built into the engine. Others use custom prefetch implementations and logic that tunes how far ahead each query reads. All of them share one goal: hiding storage latency so queries spend less time waiting on I/O and more time doing useful work. What this means for you As a fully managed service, our goal is to delight customers with a best-in-class PostgreSQL experience. You shouldn't have to think about kernel caches, buffer rings, or prefetch windows—that is our job. HorizonDB retains full PostgreSQL compatibility, so applications keep the familiar Postgres programming interface while the engine is tuned to deliver predictable performance on the storage underneath

Azure Document Intelligence and Azure Content Understanding: a practical guide

Wed, 07 Oct 2026 18:45:01 +0000

Compare Azure Document Intelligence and Azure Content Understanding across extraction architectures, workload fit, Layout capabilities, deployment options, and practical evaluation criteria. The post Azure Document Intelligence and Azure Content Understanding: a practical guide appeared first on Microsoft Foundry Blog .

Calculate your projected Grow benefits by selling through Frontier Accelerate for Marketplace

Wed, 07 Oct 2026 18:01:01 +0000

Want to skip right to getting your own benefit projections? Use the Marketplace value calculator . You’ve heard of the benefits of Frontier Accelerate for Marketplace and how they help you build, publish, grow and differentiate. But what could those benefits actually mean for your business? The Microsoft Marketplace v alue c alculator in App Advisor creates a 3-year projection based on the business data you enter to better understand the potential value of selling on Marketplace while participating in Frontier Accelerate for Marketplace. Build a business case tailored to your scenario in minutes, including: Frontier Accelerate for Marketplace membership options Deal-based or revenue-percentage revenue structures, Deal specifics like average size, totals, and percentage of growth, And optional fields estimating business costs and impacts to your bottom line. Ditch the spreadsheets. The Marketplace value calculator helps you move beyond benefits tables to understand what Marketplace participation could mean for your bottom line. Calculate your own, specific projections with Frontier Accelerate for Marketplace Every software company has different revenue, growth, and Marketplace assumptions. A benefits table can help you understand what's available. But your numbers make it real. The Marketplace Value Calculator in App Advisor lets you enter your business information to produce a 3-year projection that helps you: Estimate your potential Marketplace revenue, Understand transaction costs alongside potential benefits, Build a more specific business case for selling through Marketplace, Project the value of benefits as your Marketplace performance grows, Show the difference Frontier Accelerate for Marketplace Premium can make with $2K-$2.1M in Azure credits, Model how Marketplace can help you reach more customers, simplify sales, and scale revenue through Microsoft’s global ecosystem. Instead of asking, "What benefits could we get?" you can start using these projections to ask a more specific question that drives actual business: "Based on expected growth, what would unlocking these benefits mean for us over the next 3 years?" What benefits are included in Frontier Accelerate for Marketplace? Frontier Accelerate for Marketplace provides benefits across the full Marketplace journey. Build & Publish benefits help you develop, launch, and transact your solution, with Premium participants eligible for up to $150K USD in additional technical benefits and cloud credits. When you begin generating Marketplace revenue, Grow benefits become available starting at $500 Marketplace Billed Sales (MBS), or the equivalent threshold for other qualifying solutions. And as your Marketplace business matures, Differentiate benefits help qualifying solutions unlock additional opportunities, including certified software designations and Azure IP co-sell eligibility. App Advisor brings these stages together, helping software companies evaluate the Marketplace opportunity—including revenue potential, transaction costs, and available benefits. Go beyond the calculations with App Advisor The calculator is only one action module within App Advisor, which is designed to help you streamline the build, publish, and grow path to Marketplace. The latest updates can help you understand how Frontier Accelerate for Marketplace impacts your business every step of the way: Explore available Frontier Accelerate for Marketplace benefit s across Build & Publish, Grow, and Differentiate, Calculate your projected Marketplace value with personalized revenue, cost, and benefit estimates, Accelerate solution development with B uild & P ublish benefits like technical support and cloud credits, Unlock advanced Marketplace opportunities through Solutions Partner certified software designations and Azure IP Co-sell eligibility. The goal is to give you more than a list of benefits. App Advisor helps connect what you're building and selling with the Microsoft opportunities you can work toward next. Ready to see your projected Marketplace value? Start with the Marketplace value calculator in App Advisor to create a three-year projection based on your own data. Then explore App Advisor to see how Frontier Accelerate for Marketplace can help you build, differentiate, and grow.

The Microsoft AI and Agent Platform — Securing and Governing Intelligent Agents

Wed, 07 Oct 2026 17:42:12 +0000

In Part 1 , we explored the intelligence side of the Microsoft AI and Agent Platform: how agents understand work, reason over trusted context, use models and tools, and operate across experiences such as Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry, Dynamics 365, GitHub, and custom applications. But intelligence is only half the equation. As agents move from answering questions to taking action, the security model changes. Agents can retrieve sensitive data, call APIs, invoke tools, trigger workflows, collaborate with other agents, remember context, and act with delegated or assigned authority. That creates a new enterprise requirement: agents must be not only useful, but also governable, observable, contained, policy-driven, auditable, and aligned with organizational risk boundaries. The core question for enterprise AI is no longer only, “Can the agent reason?” It is also, “Can we trust what it can access, what it can do, how it is governed, and whether we can prove what happened?” That is the focus of Part 2: Trust —showing where security, governance, assurance, isolation, posture management, and security operations apply across the agent lifecycle. The mental model: The left side presents the seven platform layers, while the foundation establishes security across the architecture. On the right, scoped control rails apply targeted governance through Microsoft commercial controls and open-source specifications, with each control operating within its defined scope. Trust is not a feature. It is a platform property. Many early AI security conversations focused narrowly on prompts: prompt injection, jailbreaks, harmful content, and model outputs. Those risks remain important, but agentic systems broaden the attack surface. An enterprise agent is not just a model endpoint. It is a system composed of: User and application interaction channels. Foundation and custom models. Agent orchestration and reasoning. MCP servers, APIs, tools, skills, and connectors. RAG pipelines and enterprise knowledge sources. Short-term and long-term memory. Identity and access controls. Runtime environments, containers, cloud PCs, and networks. Monitoring, audit, compliance, and security operations. Trust must therefore be applied across every layer. A secured agent platform needs controls before the model call, during reasoning, before and after tool execution, at data retrieval time, during output generation, and throughout runtime operation. That is why the Microsoft Security for AI Platform is best understood as an end-to-end security architecture for the AI application and agent lifecycle. The diagram follows the path from interaction channels, through the agent and grounding layers, into build and runtime environments, and finally into security operations. The new security boundary: from applications to agents Traditional application security assumes relatively deterministic behavior: users click buttons, applications call APIs, authorization checks enforce access, and logs record the result. Agentic systems introduce more dynamic behavior. An agent may interpret a goal, decompose it into tasks, choose tools, retrieve context, call APIs, invoke another agent, generate code, operate a browser, or take action through a workflow. That flexibility is where business value comes from, but it also means controls must cover more than static application paths. A secure AI platform must answer several questions: Trust question Why it matters Who is the user and who is the agent? Agents need identity, permissions, ownership, lifecycle, and accountability. What data can the agent retrieve? RAG and grounding can expose overshared or sensitive enterprise data. What tools can the agent use? APIs, MCP servers, connectors, and skills become action surfaces. When does a human need to approve? High-impact actions require explicit approval and evidence. Where does the agent run? Runtime isolation matters when agents execute code, use browsers, or automate legacy apps. What happened? Security teams need traces, logs, detections, investigations, and audit records. How do we govern at scale? Enterprises need policy, posture management, compliance, and lifecycle controls across thousands of agents. Microsoft’s approach is to apply a consistent trust foundation across the same layers that deliver intelligence: interaction channels, AI applications and agents, data and context, build platforms, runtime infrastructure, and security operations. 1. Secure the AI interaction channels Agents enter the enterprise through many channels: Microsoft 365 Copilot, Teams, SharePoint, Office, Dynamics 365, custom portals, APIs, MCP endpoints, web experiences, and developer tools. Each channel has a different risk profile. Microsoft 365 Copilot and business application experiences inherit enterprise identity, compliance, and data protection controls from Microsoft 365, Microsoft Entra, Microsoft Purview, and Microsoft Defender. Custom apps, web apps, and API-driven experiences require the same rigor: authentication, authorization, network controls, input validation, logging, monitoring, and response. For developer tools, GitHub Advanced Security, Microsoft Defender for DevOps, Microsoft Defender for Cloud, and Microsoft Security Copilot help protect the software supply chain behind AI applications. Agent systems often depend on code, prompts, infrastructure-as-code, container images, packages, actions, connectors, and deployment pipelines. Those assets need the same scanning, secret detection, dependency governance, and posture management expected of any production system. For APIs and MCP servers, Azure API Management, Microsoft Defender for APIs, Microsoft Entra, Conditional Access, Private Link, and network controls become especially important. Agent tool use should be explicit, least privileged, monitored, and policy governed. Microsoft Defender for Cloud Apps also plays an important role across interaction channels by helping organizations discover and govern SaaS usage, manage OAuth app risk, apply session controls, and understand shadow AI exposure across the enterprise. 2. Secure the AI application and agent layer The AI application and agent layer is where models, agents, MCP, skills, hooks, RAG, memory, and orchestration come together. This layer sets agent security apart because agents do more than process requests, they reason, make decisions, and take action. Agent harness and the agent loop An agent harness is the runtime scaffolding that turns model reasoning into a stateful agent workflow. It assembles instructions and context, coordinates model and tool calls through the agent loop, maintains session state, and applies configured approvals and observability. Because the harness mediates these interactions, it is a natural integration point for policy controls: Agent Hooks defines standardized interception points, while the Agent Control Specification (ACS) evaluates policy at those points and returns decisions for the host to enforce. The harness is not an execution-isolation boundary; tools and code may run in separate containers, sandboxes, Cloud PCs, or hosted environments that require their own security controls. Models Foundation and custom models should be governed through approved model catalogs, deployment policies, evaluation pipelines, content safety controls, and monitoring. Microsoft Foundry provides a governed environment for model selection, evaluation, deployment, and operations. Model choice should be treated as a policy decision, not an uncontrolled developer preference. Different workloads may require different tradeoffs across cost, latency, quality, data handling, region, safety, and compliance. Enterprises need visibility into which models are used, for which workloads, and under which controls. Azure AI Content Safety, available through Microsoft Foundry capabilities, helps protect AI applications from harmful content, prompt attacks, jailbreak attempts, unsafe outputs, and other content risks. Content safety should be treated as part of the AI control plane, not a bolt-on filter at the edge. Agents Agents need their own lifecycle: discovery, ownership, identity, permissions, classification, monitoring, and retirement. Agent 365 helps organizations discover, inventory, govern, and enforce policies across their agent estate, preventing it from becoming an unmanaged shadow application layer. This matters because agent sprawl can become the next application sprawl. Without inventory and governance, organizations may not know which agents exist, who owns them, what data they access, what tools they can invoke, or whether they are still needed. Microsoft Purview complements this by helping protect and govern the data agents use, including sensitivity labels, data loss prevention, audit, compliance, and data security posture management for AI scenarios. Microsoft Entra provides the identity fabric for users, apps, agents, and workloads, helping ensure that agent actions are tied to explicit identities and least-privilege access. MCP, APIs, tools, and skills The Model Context Protocol and tool-based agent architectures are powerful because they let agents connect to systems of record, business applications, knowledge stores, and automation surfaces. They are also high-value control points. Every tool is effectively a capability grant. A read-only knowledge tool, a refund API, a database query tool, a ticketing connector, a browser automation tool, and a code execution tool carry very different risk. Tool authorization should be granular, contextual, and auditable. Key controls include: Tool allowlisting and approval workflows. Least-privilege API permissions. Strong authentication through Microsoft Entra. Managed identities and workload identities for secretless access. API inspection and protection with Azure API Management and Defender for APIs. Network isolation with Private Link, Azure Firewall, WAF, and DDoS Protection. Runtime isolation with containers, Microsoft eXecution Container (MXC), Windows 365 for Agents, and confidential computing where needed. Monitoring and detection through Microsoft Defender, Microsoft Sentinel, and Azure Monitor. Agent Hooks and policy gates Because the harness coordinates the agent loop, it provides a natural host-level seam for policy enforcement. Agent Hooks defines a framework-neutral interception contract across agent input, model calls, tool calls, and output. ACS can evaluate policy at those interception points, while the conforming host applies the resulting allow, deny, transform, or approval decision. Traditional framework callbacks are often designed for observability, not governance. They may observe events but not reliably block actions, transform content, bind approvals, or produce enforceable evidence. Agent Hooks introduces a framework-neutral governance contract for AI agents with defined interception points across the lifecycle, including startup, input, model calls, tool calls, output, and shutdown. Agent Hooks and the Agent Control Specification are open, design-partner-informed control contracts for agent hosts and frameworks. They define where policy decisions can be requested and what obligations a conformant host has when a verdict requires blocking, approval, transformation, or record generation. If a policy denies a tool call, the tool should not execute. If a post-tool response is denied, it should not enter agent state. If approval is required, the approval should bind to the exact action and content that was reviewed, not loosely to a session. Agent Hooks complements, but does not replace, runtime isolation. It helps govern cooperative agent host; it does not sandbox the host, tools, or untrusted code. It therefore works alongside the Agent Control Specification, Microsoft Foundry control plane, Agent 365, Microsoft Agent Framework, Microsoft eXecution Container (MXC), and Windows 365 for Agents to combine policy governance with secure execution. RAG and knowledge grounding Agents become more useful when they can ground reasoning in enterprise and external context. But grounding also expands the agent’s trust boundary by introducing additional data sources, retrieval paths, indexes, and content into the reasoning process. Securing and governing these grounding sources is addressed in the next section as part of the data and context layer. 3. Govern data and context The data and context layer is where enterprise knowledge becomes available to AI applications and agents and where existing data-security and governance boundaries must continue to hold. Agents may ground their reasoning across enterprise data, Work IQ, Fabric IQ, Foundry IQ, Web IQ, Azure AI Search, Microsoft Graph, and other organizational knowledge sources. These sources can provide valuable context, but each introduces its own authorization model, data boundary, retrieval path, and governance requirements. Trust therefore depends not simply on connecting agents to more information, but on ensuring that grounding does not create a new path around the controls protecting that information. Securing grounding starts with identity and authorization. Retrieval should preserve the permissions of the underlying source wherever supported and ensure that users, agents, applications, and workload identities can access only the information required for the task. Microsoft 365 Copilot respects Microsoft 365 user permissions and supported Microsoft Purview protections; other grounding architectures require source-specific configuration and validation. Access through Microsoft Graph, Azure AI Search, Microsoft Fabric, Microsoft Foundry, or other retrieval mechanisms should similarly be designed around explicit identities, least privilege, and the authorization boundaries of the underlying data. Data protection must extend through the grounding pipeline. Sensitive information can exist not only in source documents and databases, but also in indexes, retrieved passages, embeddings, prompts, agent memory, model responses, logs, and downstream actions. Applicable sensitivity labels, information protection, DLP, retention, audit, encryption, and compliance controls should therefore be considered across the complete flow of grounded information rather than only at the original data source. Grounding also introduces risks that traditional access control alone does not address. Overshared content can become overshared AI context; stale or low-quality information can influence agent decisions; compromised or untrusted sources can introduce poisoned content; and instructions embedded in retrieved content can attempt to manipulate agent behavior through indirect prompt injection. Organizations should therefore govern which sources can be used for grounding, validate the trustworthiness and freshness of those sources, protect retrieval and indexing pipelines, and apply appropriate evaluation, monitoring, and content-safety controls. For retrieval-based architectures, indexes and knowledge stores should be treated as governed enterprise assets. Organizations should understand what information is indexed, where it originated, how frequently it is refreshed, which identities can query it, how access controls are enforced, and whether retrieved content can cross security or data boundaries. Retrieval relevance alone is not sufficient; the retrieval path must also preserve the security intent of the source system. This is particularly important for Microsoft 365 grounding. Microsoft Purview helps protect and govern sensitive information through capabilities such as information protection, DLP, audit, retention, compliance, and data security posture management. Microsoft Entra provides identity and access controls for users, applications, agents, and workloads. SharePoint Advanced Management can help organizations address oversharing and content-governance risks in the SharePoint estate used by Microsoft 365 Copilot and agents. Other grounding environments require equivalent controls appropriate to their data sources, identities, retrieval architecture, and runtime. The same principles apply across Work IQ, Fabric IQ, Foundry IQ, Web IQ, enterprise data, Azure AI Search, and Microsoft Graph, but the controls should not be assumed to operate identically across them. Their integration models, permissions, governance capabilities, and maturity differ. Organizations should validate the security boundary of each grounding source and explicitly determine how identity, authorization, data protection, retrieval, monitoring, and audit requirements are enforced for that implementation. A trusted grounding architecture should therefore answer several questions: Who or what is requesting the information? Is that identity authorized to retrieve it? Is the source approved and trusted for grounding? Does retrieval preserve the source system's access boundaries? Is sensitive information protected throughout retrieval, indexing, reasoning, memory, and output? Can retrieved content introduce malicious or untrusted instructions into the agent? Are indexes and knowledge stores governed, current, and appropriately isolated? Can organizations observe and audit how grounded information is being accessed and used? The principle is straightforward: grounding should extend enterprise context to agents without weakening the identity, security, privacy, and governance boundaries of the underlying information. A trusted agent should retrieve not simply the most relevant information, but the right information, from trusted sources, through authorized paths, under controls the organization can govern and audit. 4. Secure the build continuum: no-code, low-code, and pro-code Microsoft’s platform supports multiple build paths: Agent Builder for no-code creation, Copilot Studio for low-code agents and orchestration, and Microsoft Foundry for pro-code AI systems. AI solutions can cross boundaries, and security must travel across that continuum. Build path Primary audience Trust requirements Microsoft capabilities Guided/ No-code Business users and teams Agent discovery, ownership, sharing controls, data governance, policy enforcement Microsoft Agent 365, Microsoft Purview, Microsoft Entra, Microsoft Defender Managed/ Low code Makers, process owners, business technologists Connector governance, environment strategy, DLP, approvals, lifecycle management Copilot Studio, Power Platform DLP, Managed Environments, Entra, Purview, Agent 365 Code-first/Custom Developers and platform teams Secure SDLC, evaluations, red teaming, DevSecOps, runtime isolation, observability Microsoft Foundry, GitHub Advanced Security, Defender for DevOps, Defender for Cloud, Azure Monitor No-code: Agent Builder No-code agents make AI creation accessible to more users, which increases business agility and helps organizations bring AI into the flow of work. The trust requirement is to make that creation visible and governable without removing the simplicity that makes no-code valuable. Microsoft Agent 365 helps provide agent discovery, inventory, lifecycle management, policy enforcement, and governance across the agent estate. Microsoft Purview helps ensure that the data used by these agents remains protected by sensitivity labels, DLP, audit, and compliance controls. Microsoft Entra helps enforce identity, access, and least privilege. Together, these capabilities allow organizations to empower business users while maintaining enterprise trust. Low code: Copilot Studio Copilot Studio brings orchestration, connectors, workflows, and extensibility. That makes Power Platform governance important because low-code agents often sit close to real business processes and enterprise data. Power Platform DLP policies, Managed Environments, environment strategy, connector governance, solution lifecycle management, maker and admin roles, and approval patterns for sensitive actions are the mechanisms that turn low-code agility into trusted enterprise automation. These controls help organizations decide which connectors can be used together, which environments are appropriate for development and production, who can build and publish agents, how solutions move through lifecycle stages, and when human approval is required before action is taken. Low-code agents need both business speed and enterprise control. Trust is what allows organizations to scale low-code innovation beyond isolated pilots. Pro-code: Microsoft Foundry Pro-code agent systems demand rigorous software engineering: secure architecture and coding, dependency governance, CI/CD safeguards, container security, infrastructure-as-code scanning, environment isolation, observability, evaluation, and incident response. GitHub Advanced Security and Microsoft Defender for DevOps are central to this approach. GitHub Advanced Security supports code and secret scanning, dependency review, and software supply-chain protection. Defender for DevOps brings these findings into Microsoft Defender for Cloud, giving security teams a unified view of AI application, cloud, and workload risks. AI-specific assurance should also be embedded in the development lifecycle. Open-source tools such as PyRIT, RAMPART, ASSERT, and the Agent Governance Toolkit support red teaming, behavioral evaluation, governance evidence, and regression testing. Open specifications such as Agent Hooks and the Agent Control Specification establish interoperable control patterns across agent hosts and frameworks. These open-source tools give organizations transparent, extensible ways to test and standardize AI security across heterogeneous environments. For enterprises using multiple frameworks, models, clouds, APIs, and orchestration approaches, PyRIT, RAMPART, ASSERT, and the Agent Governance Toolkit provide practical methods to red-team, evaluate, govern, and validate systems. Agent Hooks and the Agent Control Specification complement them with a common language for integrating controls at the host level. Microsoft commercial solutions operationalize these controls at enterprise scale. Microsoft Agent 365, Microsoft Foundry, Microsoft Entra, Microsoft Purview, Microsoft Defender, Microsoft Sentinel, Microsoft Security Copilot, GitHub Advanced Security, and Azure infrastructure services provide the inventory, policy enforcement, data governance, monitoring, detection, response, compliance, and operational capabilities required for production environments. The roles are complementary: open-source tools promote transparency, interoperability, and technical assurance, while commercial solutions provide enterprise control planes, integrated operations, support, and scale. Together, they help customers and partners secure AI systems from experimentation through production. 5. Secure runtime, isolation, and execution Once agents are built, they need somewhere to run. The runtime layer determines how agents are isolated, monitored, scaled, and connected. Key runtime and infrastructure components include Microsoft Foundry, Azure AI Search, Azure Confidential Computing, Azure Kubernetes Service, Azure Container Apps, Azure Functions, Azure Private Link, Storage, Azure Firewall, WAF, DDoS Protection, Azure Monitor, Azure Policy, Windows 365 for Agents, and Microsoft eXecution Container (MXC). AI applications and agents need more than access to a model. They require secure infrastructure to host orchestration, retrieve knowledge, execute tools, process files, automate workflows, connect privately to enterprise systems, maintain state, enforce policy, and capture telemetry. This foundation turns prototypes into resilient, governable production systems. Strong infrastructure controls are especially important because agents may execute code, invoke tools, operate browsers, process files, and interact with systems that were not designed for autonomous actors. Microsoft eXecution Container (MXC) and Windows 365 for Agents are especially important for secure execution. Microsoft eXecution Container (MXC) – (in early preview now) is a sandboxed code-execution capability designed to provide isolated execution environments for agent actions and code. Windows 365 for Agents provides managed Cloud PC environments for agents that need to interact with desktop applications, browsers, or legacy systems that do not expose APIs. Azure Confidential Computing can help protect sensitive workloads in use. Azure Private Link keeps traffic private. Azure Policy enforces guardrails. Azure Monitor and Application Insights provide telemetry. Azure Key Vault and Managed HSM protect secrets and keys. Managed identities and Microsoft Entra Workload ID reduce the need for long-lived secrets. Azure Container Registry and Defender for Containers help protect image-based agent workloads. As agent autonomy and tool access increase, runtime isolation, oversight, and monitoring must strengthen accordingly. 6. Manage runtime security posture Runtime security posture provides a continuous view of whether AI applications, agents, tools, and infrastructure remain within expected security boundaries. Layer 5 defines where and how agents run; Layer 6 assesses whether those environments are hardened, observable, compliant, and improving over time. For agentic systems, posture management must combine traditional cloud controls with AI-specific oversight. Security teams need visibility into AI services, agent workloads, containers, APIs, model endpoints, grounding stores, identities, secrets, and network paths. They must also identify public exposure, missing telemetry, excessive permissions, vulnerable images or packages, unprotected data stores, and access to unapproved tools or data sources. Microsoft Defender for Cloud anchors this layer. Cloud Security Posture Management identifies misconfigurations, excessive permissions, exposed resources, weak network paths, encryption gaps, and compliance issues across cloud workloads. Defender for Containers extends that visibility to images, registries, clusters, and runtime risks. Defender for AI services threat protection and AI Security Posture Management add AI-specific discovery and protection, surface risky configurations, and connect those findings to broader cloud and workload risk. Effective runtime posture also requires identity and data context. Microsoft Entra, managed identities, Entra Workload ID, Conditional Access, and Privileged Identity Management help reduce standing privilege and reliance on secrets. Microsoft Purview adds sensitivity, DLP, audit, retention, compliance, and data-security posture signals. Agent 365 and Microsoft Foundry add context about agent inventory, ownership, evaluations, guardrails, model endpoints, and lifecycle state. The goal is not to generate more recommendations, but to prioritize the risks that matter most in production: exposed agent endpoints, unmanaged MCP tools or APIs, overprivileged workload identities, vulnerable containers, missing telemetry, unprotected secrets, overshared grounding data, noncompliant model deployments, and runtime environments that do not match an agent’s autonomy. These posture signals should flow into security operations. Defender XDR, Microsoft Sentinel, Microsoft Security Exposure Management, and Security Copilot can combine posture, exposure, detection, and audit data to help defenders investigate agent behavior, trace attack paths, and coordinate response. This connects build-time assurance, runtime isolation, continuous posture management, and security operations. 7. Operationalize AI security across the Microsoft Platform AI security must extend beyond design and deployment into continuous operations. As agents move into production, organizations need to connect agent and application governance, identity, data security, cloud and workload protection, exposure management, detection, investigation, and response so agent activity can be understood and governed in the context of the broader enterprise environment. Microsoft provides complementary control planes across this operating model. Microsoft Agent 365 and Microsoft Foundry Control Plane help govern the agent estate and AI platform; Copilot Studio and Power Platform governance provide environment, connector, and DLP controls for low-code agents and applications; Microsoft Entra governs identity and access; Microsoft Purview protects and governs data; and Microsoft Defender, Microsoft Security Exposure Management, Microsoft Sentinel, and Microsoft Security Copilot extend protection, exposure management, detection, investigation, and response across the environment. Microsoft Security provides an integrated operating model across these domains: Security capability Microsoft solutions Agent and application governance Microsoft Agent 365, Microsoft Foundry Control Plane, Copilot Studio and Power Platform governance, Managed Environments, Power Platform DLP Identity and access security Microsoft Entra, Conditional Access, Identity Protection, Privileged Identity Management, Workload ID, Agent ID Data security and compliance Microsoft Purview, Data Security Posture Management, Information Protection, DLP, Audit, eDiscovery Cloud, workload, and AI protection Microsoft Defender for Cloud, Defender CSPM and AI security posture management, Defender for AI Services, Defender for Containers Endpoint and user protection Microsoft Defender XDR, Defender for Endpoint, Microsoft Intune API and application protection Azure API Management, Defender for APIs, Defender for Cloud Apps Exposure management Microsoft Security Exposure Management, Defender External Attack Surface Management Security operations Microsoft Defender XDR, Microsoft Sentinel DevSecOps and software assurance GitHub Code Security, GitHub Secret Protection, Defender for DevOps, MDASH Secrets and network protection Azure Key Vault, Managed HSM, Azure Firewall, WAF, DDoS Protection, Private Link, Global Secure Access For agentic systems, this connected view is especially important. An agent may authenticate with one identity, retrieve sensitive data from another system, invoke APIs or MCP tools, execute code in a runtime, and take action in a business application. Security operations therefore need to correlate relevant identity, data, application, API, cloud, endpoint, workload, and agent signals rather than assess each component in isolation. Posture, exposure, telemetry, detections, and audit signals can then help defenders understand suspicious agent activity in context—for example, an over-permissioned identity, exposed API, vulnerable runtime, unusual data access, or anomalous agent behavior. The goal is not to create a separate security operations model for AI, but to extend existing enterprise security operations to AI applications and agents. Defend with AI Trust also means moving from defending AI to defending with AI. Microsoft is applying AI across security operations, software assurance, and proactive threat discovery to help defenders identify risk, investigate threats, and accelerate response. Microsoft Security Copilot augments security teams with AI-assisted investigation, incident summarization, signal correlation, query generation, and response workflows. Codename MDASH, currently in preview, is Microsoft’s multi-model agentic scanning harness, an agentic code scanner in Microsoft Defender that coordinates specialized agents and models to discover, validate, and help remediate source-code vulnerabilities. Project Perception, currently in limited preview, coordinates red, blue, and green team agents to uncover weaknesses, investigate threats, and recommend or perform approved remediation. Together, these capabilities demonstrate the next evolution of security operations: using security to protect AI while using AI to strengthen security combining human expertise with AI-assisted and agentic defense across prevention, exposure management, detection, investigation, and response. Apply security foundations across every layer Security foundations provide consistent principles that underpin trust across the AI and agent lifecycle. Zero Trust, encryption, observability, continuous monitoring, Responsible AI, and governance become actionable when they are applied as concrete controls across identity, data, applications, agents, tools, grounding, and runtime environments. Zero Trust: Verify explicitly, enforce least privilege, and assume breach across user, agent, workload, tool, data, and runtime access. Encryption: Protect prompts, responses, grounding data, memory, logs, and tool payloads at rest, in transit, and where supported, in use. Observability and logging: Capture relevant agent activity including tool calls, data access, policy decisions, approvals, errors, and outcomes with appropriate privacy controls. Responsible AI and governance: Evaluate agents for safety, reliability, privacy, security, transparency, and accountability before and after deployment. Continuous monitoring: Monitor for drift, misuse, anomalous behavior, unexpected data access, and emerging threats as models, data, and tools change. Audit and accountability: Maintain evidence of who initiated an action, which agent acted, what resources were accessed, which controls were applied, and what outcome occurred. Privacy and data protection: Apply appropriate information protection, DLP, retention, audit, and compliance controls across prompts, grounding, memory, outputs, logs, and downstream actions. These controls must operate continuously across the agent lifecycle. As agents move from design and build through grounding, deployment, monitoring, and response, their models, data, tools, identities, permissions, and runtime environments will continue to change. Trust therefore cannot be established once at deployment; it must be continuously evaluated, governed, monitored, and improved as the agent and its operating environment evolve. The outcome: trusted autonomy Trust is not a constraint on AI transformation; it is what enables AI to scale responsibly across the enterprise. As organizations move from assistive copilots to increasingly autonomous agents and multi-agent systems, they need confidence that those systems operate within clear boundaries for identity, data access, tool use, execution, governance, and accountability. The goal is not to eliminate autonomy, but to make autonomy intentional, bounded, observable, and governable. Microsoft brings together AI platforms with identity, data security, application security, cloud and runtime protection, security operations, and open security tooling to help organizations establish these boundaries across the agent lifecycle. Rather than creating a separate security model for every agent, framework, runtime, or data source, organizations can apply a consistent trust architecture while adapting controls to the risk and autonomy of each scenario. This is trusted autonomy: enabling agents to reason and act with increasing independence while keeping their access, actions, and outcomes within enterprise-defined security and governance boundaries. Combining the intelligence that makes agents useful with trust that allows organizations to deploy them confidently at enterprise scale. Intelligence + Trust = Frontier Transformation.

Moore's Law has an end date

Wed, 07 Oct 2026 17:22:44 +0000

Back in 2008, Michio Kaku told me Moore's Law would hit a wall around 2020. Chips so hot you could fry an egg on them. Did he call it? You tell me. Full episode: https://hanselminutes.com/101 #shorts

Lessons Learned #556: Finding the SQL Statement Behind a Query Hash in Azure SQL Database

Wed, 07 Oct 2026 17:15:14 +0000

Recently, I worked on a performance investigation in which several queries were identified by their query hashes. The hashes helped us discuss the workload, but the customer still needed to answer a practical question: which SQL statements were behind them? A value such as 0x0123456789ABCDEF does not tell an application developer which statement to review. Fortunately, if Query Store captured the query and still retains it, the customer can use that hash to find the SQL text and the query ID in their own database . In this article, I will show that lookup and explain what to do with the result. The hash used below is a placeholder; replace it with a hash from your investigation. A hash is a lookup key rather than the SQL text A query hash is an eight-byte value derived from the shape of a query . It cannot be decoded back into the original statement. We need a source that stores the relationship between the hash and the text. Query Store provides that relationship through two catalog views. sys.query_store_query contains the query hash and query ID. Its query_text_id links to sys.query_store_query_text , where we can retrieve the SQL text. That gives us a small, read-only query to answer the customer’s question. Find the statement in the correct database Connect directly to the Azure SQL Database that executed the workload, rather than master or another database on the same logical server. Use an account with the permissions required to read Query Store information. Then run the following query, replacing the example hash: DECLARE @QueryHash binary(8) = 0x0123456789ABCDEF; SELECT CONVERT(varchar(18), q.query_hash, 1) AS query_hash, q.query_id, q.context_settings_id, qt.query_sql_text FROM sys.query_store_query AS q JOIN sys.query_store_query_text AS qt ON qt.query_text_id = q.query_text_id WHERE q.query_hash = @QueryHash ORDER BY q.query_id; Use the hexadecimal value with its 0x prefix, as shown, without quotation marks. The returned hash is formatted in the same hexadecimal notation so you can compare it with the original value. This lookup does not need a date filter: it searches the query records that Query Store currently retains. Reviewing performance during a particular incident is the next step, after identifying the matching queries. One hash can return more than one query ID Suppose the lookup returns query IDs 125 and 206 . Those are illustrative IDs, but they show an important point: we should inspect both rows rather than select the first one automatically. Each query ID can also have more than one execution plan. This simple lookup intentionally returns query records without joining the plan table, so multiple plans do not repeat the SQL text in the results. Use the query ID to continue in SSMS Once the text is identified , the hash has done its job. In SQL Server Management Studio, expand the database, open Query Store, and select Tracked Queries. Enter a returned query ID and choose the period you want to investigate. From there, review the available execution plans and compare CPU, duration, reads, and execution frequency . Repeat the review for other matching query IDs where necessary. Finding the statement does not prove that it caused a particular resource spike. That conclusion still requires performance statistics and an appropriate time correlation. The useful outcome here is that the customer now knows which SQL statement to review. What if the lookup returns no rows An empty result does not prove that the query never ran . First confirm the database and the hash. Then check whether Query Store captured the query and whether its history remains available. Capture policy, cleanup, or Query Store being disabled during execution can explain a missing record. Enabling Query Store now cannot recreate a statement that was never captured. I f the workload runs again, capture it and repeat the lookup after verifying that Query Store is collecting the relevant activity. References sys.query_store_query and the query hash . sys.query_store_query_text and SQL text . Monitor performance using Query Store .

Anyscale on Azure is now Generally Available

Wed, 07 Oct 2026 17:12:20 +0000

Anyscale on Azure is now Generally Available. Enterprises can run the Ray distributed runtime as a managed service on Azure Kubernetes Service (AKS), with workloads running in the customer’s own Azure subscription, network, and identity boundary. With General Availability, Anyscale on Azure is ready for production workloads and comes with the commitments enterprises need. It is backed by a service level agreement and production support from both Microsoft and Anyscale. Customer workloads, datasets, and model artifacts run in their Azure subscription, while Anyscale operates the control plane in its own Azure tenant. Customers can use their Azure identity and governance controls for the resources in their subscription. Xoople is already using Anyscale on Azure to turn planetary-scale satellite imagery into decision-ready intelligence. AI systems need more than a good model Model quality is only part of the challenge. Enterprises must also connect, secure, and operate the stages around the model. A typical stack assembles one tool for data preparation, another for distributed training, a third for evaluation, and a fourth for serving. Each tool solves part of the problem. Connecting them can require custom integration code, separately provisioned compute, and security controls that teams must maintain across systems. The resulting challenges fall into four areas: Utilization : GPUs provisioned per stage can sit idle while another stage waits for capacity. Reserved capacity that is idle is still billed. Security and governance : Teams must manage who can access data and models, where they are processed, and how security controls are configured across each system and handoff. Engineering time : Integration code requires ongoing maintenance, monitoring, and troubleshooting alongside the tools themselves. Development cycle time : Handoffs between stages can slow the path from experimentation to production. Anyscale on Azure addresses this fragmentation by bringing data preparation, training, evaluation, and inference into a common runtime and operational model. Shared infrastructure can reduce idle compute capacity, while managed Ray cluster lifecycles reduce the infrastructure work teams perform themselves. Workloads, datasets, and model artifacts remain in the customer’s Azure subscription, where teams configure access and networking controls. Using a common runtime across stages can also reduce the need to maintain separate compute stacks. The goal is to support an AI learning loop, not just inference: production feedback informs data curation, training or post-training, and evaluation before updated models return to serving. Anyscale provides the common compute platform; teams remain responsible for their models, evaluation criteria, application workflows, and security configuration . How Anyscale on Azure w orks Anyscale on Azure is an Azure Native Integration with an Anyscale-operated control plane and a customer data plane that keeps core resources in the customer’s Azure tenant, helping teams maintain their security and data-residency requirements. Anyscale hosts and operates the control plane in Azure. You reach it from the Azure Portal, the Anyscale console, or the Anyscale CLI and SDK. The data plane runs entirely inside your own Azure subscription: Anyscale deploys an operator into your AKS cluster, which manages Ray cluster lifecycles on your behalf. This keeps Ray workloads, datasets, and model artifacts in your Azure subscription, while the Anyscale-hosted control plane processes operational metadata. Workloads run on AKS within your virtual network and use your existing Microsoft Entra ID, Azure RBAC, and private networking controls. The Anyscale operator and Ray clusters initiate outbound connections to the Anyscale control plane, so Anyscale does not require inbound firewall access to AKS nodes for those connections. Anyscale on Azure integrates with Azure Managed Identities for authentication, Azure Blob Storage and ADLS for data, Azure Key Vault for secrets, and Azure Container Registry for images. Use familiar Azure identity and resource controls Anyscale on Azure is backed by Azure Resource Manager, allowing platform teams to apply Azure Policy and discover Anyscale resources through Azure Resource Graph, just as they do with other Azure resources. Control How it works on Anyscale on Azure Provisioning A guided Azure Portal flow provisions storage, managed identity, container registry, and service account, then installs the Anyscale operator. ARM templates and Terraform are supported. Identity Sign-in runs through Microsoft Entra SSO. Conditional Access policies that govern Azure portal sign-in govern Anyscale sign-in too. Authorization Azure RBAC against your existing role assignments, with three built-in Anyscale roles as a starting point. Policy Platform teams can apply Azure Policy to supported Azure resource types. Validate policy coverage for the Anyscale resource and its underlying infrastructure. Private connectivity Connect the Anyscale operator and Ray clusters on AKS to Anyscale control plane through a private endpoint in the customer’s virtual network. Outbound traffic travels over the Microsoft backbone rather than the public internet. Cost visibility Usage appears in Microsoft Cost Management and on the same Azure invoice, drawing down against MACC. Data boundary Ray workloads run on AKS, with datasets and model artifacts in your subscription; operational metadata is managed separately. For regulated industries such as financial services, healthcare, and public sector, Anyscale on Azure makes in-tenant AI attainable. In production: Xoople Xoople is building what it calls Earth's system of record, a continuously updated and AI-ready picture of how the planet's surface is changing. The workload is a useful illustration of why a unified runtime matters. Turning raw spectral data from satellite constellations into decision-ready measurements is not primarily a model problem. It is continuous, large-scale, heterogeneous computation: ingest and reprojection, calibration, feature extraction, model training, and inference, each at a different shape and each needing different hardware. With Anyscale on Azure, Xoople can reliably run massively distributed AI workloads over planetary-scale satellite imagery, transforming complex spectral data into decision-ready intelligence. Anyscale lets our teams focus on models and outcomes rather than infrastructure, dramatically accelerating the path from experimentation to deployment. — Milos Colic, VP of Engineering, Xoople Workloads teams run on Anyscale on Azure Workload What it's used for Why it fits a unified runtime Multimodal data preparation Curating and preparing image, video, text, and sensor datasets for training CPU decoding and GPU model-based processing run in one pipeline, with no handoff between systems Distributed training and fine-tuning Scaling distributed training across available GPU capacity Checkpointing and, when using Ray Data for data loading, mid-epoch resume can reduce repeated work after interruptions Composite AI serving Deploying and orchestrating multi-model AI applications in production Ray Serve runs multiple models and steps as a single service Embedding generation Producing embeddings at scale for search and retrieval CPU preprocessing and GPU inference share one cluster and one scheduler Reinforcement learning for LLMs Coordinating parallel reinforcement-learning post-training workloads Rollouts, reward scoring, and training are coordinated in one Ray program Physical AI simulation Running thousands of concurrent simulation environments Ray schedules large numbers of parallel simulations alongside training One runtime for the entire AI lifecycle One Ray runtime supports data preparation, training and fine-tuning, batch and online inference, and long-running agentic workloads. When each stage has its own compute, capacity reserved for one can sit idle while another waits. A shared scheduler reallocates compute as demand shifts, which can reduce idle capacity and lower infrastructure costs. Model choice also matters. Fine-tuned, task-specific models can cut serving costs when they meet quality requirements, so weigh total cost, not inference alone. The Anyscale Runtime supports Ray APIs, so existing Ray code needs fewer changes to move over. Customers should validate dependencies, data access, networking, and deployment configuration. Get started Anyscale on Azure is provisioned from the Azure Portal onto an AKS cluster in your own subscription. You manage and monitor deployments from Portal, and use the Anyscale console, CLI, and SDK for cluster-level work. Review the Anyscale on Azure overview on Microsoft Learn for architecture and prerequisites. Check regional availability against where your data resides. Create an Anyscale cloud on an existing AKS cluster from the Azure Portal, then configure managed identities for access to Blob Storage, Key Vault, and Container Registry. Move an existing Ray workload using compatible Ray APIs, after validating dependencies and deployment configuration, or start from the Anyscale on Azure quickstart . Check current Azure pricing and offer eligibility before assuming free-account credits apply to Anyscale on Azure usage. Resources Anyscale on Azure architecture and overview Anyscale on Azure pricing Anyscale on Azure solution page Anyscale on AKS Terraform reference deployment Anyscale on Azure public preview announcement Anyscale on Azure press release, June 2, 2026 Announcing Anyscale Runtime Ray on AKS overview

[Launched] Generally Available: Anyscale on Azure

Wed, 07 Oct 2026 17:06:00 +0000

Anyscale on Azure is now Generally Available. Anyscale on Azure is a managed platform for running distributed Python workloads on Ray. It deploys directly onto your Azure Kubernetes Service (AKS) cluster and integrates with the Azure services your team al

Closing the AI Agent Governance Gap with Microsoft Foundry

Wed, 07 Oct 2026 17:00:00 +0000

Developers are shipping agents faster than security teams can catalog them. As organizations move beyond pilots and begin operating dozens or hundreds of agents, one question keeps coming up: how do we actually get visibility into our AI agents across our environment? In this article, we'll walk through how Azure services can help establish visibility, guardrails, and cost accountability across your AI estate. Governance for AI happens across four layers: Resources – who can create new AI resources Builders – who can develop and publish agents in a certain scope Behavior – how agent outputs are evaluated, monitored, and governed Dependencies – what models, tools, APIs, and MCP servers agents can interact with Most organizations already have governance controls for identities, networking, and compliance. The challenge isn't creating new controls. It's connecting existing controls into an operating model that works for AI agents. Below we walk through each area and go a bit deeper on how to close the gap. Setting up boundaries with Azure Policy First, let's start in the Azure portal with Azure Policy. Azure Policy lets you set guardrails on what can be deployed in your environment and flags or blocks anything that doesn't comply. For AI workloads, the built-in definitions range from limiting models that people in your organization can deploy to locking down the network through enabling private endpoints. Some policies you get started with: Foundry model deployments should only use approved models: Restricts deployments to models or publishers your organization has explicitly approved Foundry model deployments should meet eligibility requirements (preview): Applies rules based on model attributes like preview vs. GA status and distribution source Azure AI Services resources should have key access disabled: Makes Microsoft Entra ID the only entry point The full list of policies related to Azure AI Services are available here: List of built-in policy definitions - Azure Policy | Microsoft Learn Why this comes first: Policy checks resources before they are created, so it proactively keeps your environment aligned with your standards. Implementing role-based access control (RBAC) Once these boundaries are in place, the next step is RBAC. Setting RBAC up early ensures that people and identities building agents have the right scope for what they actually need to do. Foundry roles only apply when you authenticate using Microsoft Entra ID. If you're using key-based authentication instead, the key grants full access with without role restrictions. API keys are convenient for quick development usage but when moving towards production, Microsoft Entra ID is the preferred method. Roles can be assigned at three scopes: the Foundry resource, a Foundry project, or an individual agent itself. Below is an example of how different personas within organization can map to a certain scope for creating and building agents with Foundry. Here's how each role in the diagram compares, from least to most privileged: Role Privilege Level What it does in Microsoft Foundry Foundry Agent Consumer Least Interact with agent endpoints in a project. This is your least-privilege role for people who only need to use agents. Foundry User Low Grants reader access to the Foundry project, the Foundry resource, and data actions for your Foundry project. Least-privilege access role for developers building and testing agents. Foundry Project Manager Medium This role lets you perform management actions on Foundry projects, build and develop with projects, and conditionally assign the Foundry User role to other user principals. Foundry Account Owner Higher Grants full access to manage Foundry projects and resources, and lets you assign the Foundry User role to other user principals. Foundry Owner Highest Grants full access to manage Foundry projects and resources to build and develop with projects. This role can also assign the Foundry User, ACR, and monitoring roles to users in the environment. Source: Role-based access control for Microsoft Foundry - Microsoft Foundry | Microsoft Learn For the agent resources themselves, assign managed identities rather than API keys since it lowers the risk of having compromised credentials. Note if you're scripting RBAC permissions: these roles were recently renamed from Azure AI User, Azure AI Owner, Azure AI Account Owner, and Azure AI Project Manager. The role IDs and permissions didn't change, so use the role definition GUID in your code to avoid issues while the rename rolls out. Observability in Microsoft Foundry Governance requires more than access control. Organizations also need evidence of how agents are being used. Observability provides the audit trail needed to investigate incidents, understand usage patterns, and track costs. The Foundry Control Plane brings these observability and governance tools together in one place, alongside services like Azure Monitor, Microsoft Entra, Microsoft Purview, and Azure Policy. In the Foundry portal, tracing is a good starting point. Once you connect an Application Insights resource to your project, Foundry turns on tracing automatically so every run, including the ones you test in the playground, is logged. After it is completed, you can search by Response ID or Trace ID to see the conversation history, token usage, run steps, tool calls, and inputs and outputs between the user and the agent. For more granular queries, you can write KQL to dive into individual agent runs or use the prebuilt Grafana dashboards in Azure Monitor. With client-side tracing, you can also export traces to observability tools you may already use, such as Datadog or Jaeger. Note: Permissions required for viewing this telemetry requires the Log Analytics Reader role on the connected Application Insights resource, and Privileged Monitoring Data Reader on top of that if the underlying Log Analytics tables are protected. Alongside all of these monitoring features, every agent comes with content safety guardrails and evaluations let you test and optimize performance before and after you publish your agents. When agents get published to Microsoft Teams and Microsoft 365 Copilot, Microsoft 365 admins can approve usage requests. These requests can be further scoped to a limited group for pilot testing/department usage or the full organization. Adding an AI gateway Observability tells you what your agents are doing, but how do you actually control them? This is where Azure API Management comes in. Once you have more than one agent, model deployment, or multiple teams consuming them, you need a single enforcement point between the agents and the resources they call. Adding Azure API Management in front of Microsoft Foundry gives you: Rate limiting and load balancing across regions and model deployments Consistent authentication and quota policies for model and tool traffic Usage tracking per team or cost center so you can accurately charge back to different departments Governed access to your custom and remote MCP servers Note: When choosing MCP servers, start with trusted, enterprise supported sources (GitHub, Microsoft, internally developed servers, etc.) that have documented security controls, enterprise authentication, clear ownership, and least-privilege permissions. Treat community MCP servers as untrusted until they have undergone a formal security review and are verified by organizations. Adding an AI gateway completes the governance picture. Azure Policy governs what can be deployed. RBAC governs who can build and manage agents. Observability provides evidence of how agents behave in production. The AI gateway extends governance into runtime, controlling how agents interact with models, tools, and external systems. Combined, these layers help organizations move beyond simply building agents to operating them responsibly at scale. Extend governance across the wider estate A few directions to take this further: MCP registry in Azure API Center – As MCP usage grows, you can create an approved inventory of MCP servers and APIs that can be used across an organization. Microsoft Agent 365 – Microsoft's enterprise control plane for AI agents. It gives every agent its own Microsoft Entra Agent ID and published Foundry agents sync to its registry automatically. This gives your IT team one place to run access reviews, lifecycle policies, and owner attestation across every agent in the tenant, including shadow agents discovered outside Foundry. Copilot Studio – when you add an MCP tool, you can point it at the API Management URL instead of the direct remote endpoint to gain additional observability through the gateway. GitHub Copilot – you can apply the same AI gateway-fronted MCP registry, applied to the developer side. Microsoft Purview – data classification, DLP, audit, and AI interaction governance across the wider estate. Where to go next Looking for a quick start? Turn on the three Azure Policy definitions above in audit mode against a non-production subscription and see what gets flagged that is out of compliance. Ready to design the end-to-end pattern? Take a look at this Cloud Adoption Framework guidance on AI governance and governing Azure platform services for AI . Want to go deeper on agent observability? Start with these articles around Application Insights integrations with Foundry: Use Insights in Microsoft Foundry and Monitor AI Agents with Application Insights Governing AI agents doesn't require starting from scratch. The identity, policy, monitoring, and cost controls you already use for the rest of your Azure estate can extend to AI workloads. Start with one layer, connect the next, and build a governance foundation that grows with your AI adoption.

[Launched] Generally Available: Enabling the Bulk admin role for SQL Server on Linux

Wed, 07 Oct 2026 16:57:04 +0000

Starting with SQL Server 2025 CU9 and SQL Server 2022 CU27, SQL Server on Linux supports the bulkadmin fixed server role and the ADMINISTER BULK OPERATIONS permission for performing bulk data import operations without requiring users to be members of the

Is Prompting Actually Programming?

Wed, 07 Oct 2026 16:30:20 +0000

Scott breaks down why prompting AI isn’t necessarily the same as programming. If the same prompt can produce different software every time, can it really be considered code?

Scott & Mark Learn To... SemanticStart

Wed, 07 Oct 2026 16:15:07 +0000

In this episode, Scott Hanselman and Mark Russinovich dive into Mark’s new SemanticStart project, exploring how semantic search can make finding Windows apps, tools, and settings more intuitive. Along the way, they experiment with AI-assisted coding, discuss how agents could interact with local tools, and debate a bigger question: does prompting an AI actually count as programming? https://github.com/markrussinovich/SemanticStart Listen to other episodes at https://scottandmarklearn.to Discover other Microsoft podcasts at https://microsoft.com/podcasts Code: L6HFZE1K6NMCJZVH

Join the momentum building for this year's Microsoft AI Tour

Wed, 07 Oct 2026 16:00:00 +0000

The Microsoft AI Tour kicks off on October 12 and will make its way around the world with stops in key markets where business decisions are made. Become a sponsor to share your AI innovation with qualified audiences during these one-day events designed to help organizations move from AI experimentation to confident action. Visit Microsoft Event Sponsorship or contact sponsor@microsoft.com to get the 2026–2027 Microsoft AI Tour sponsorship opportunity guide. As a Microsoft sponsor, you can: Generate pipeline—make meaningful, face-to-face connections with decision-makers and practitioners across industry segments. Build brand visibility—boost your brand’s profile and strengthen your alignment with Microsoft and AI. Showcase your innovations—share our latest joint solutions in your booth and during sessions to spark interest and gain leads. Reach out to sponsor@microsoft.com to start planning your sponsorship today.

3 lessons from frontier AI vulnerability research

Wed, 07 Oct 2026 16:00:00 +0000

Read how How Microsoft Security's FORGE Lab is scaling vulnerability research from Windows to the Linux kernel. The post 3 lessons from frontier AI vulnerability research appeared first on Microsoft Security Blog .

AI transformation across the infrastructure lifecycle: From supply chain to fleet operations

Wed, 07 Oct 2026 15:00:00 +0000

The opportunity is bigger than making individual tasks faster. It’s to build a system that learns from how infrastructure is designed, sourced, and operated. The post AI transformation across the infrastructure lifecycle: From supply chain to fleet operations appeared first on Microsoft Azure Blog .

Meet Microsoft at Oracle AI World 2026

Wed, 07 Oct 2026 14:00:00 +0000

Where your Oracle data meets Microsoft AI Most enterprise AI runs into the same wall: the data lives in Oracle, and the AI lives somewhere else. Oracle AI Database@Azure closes that gap, running Oracle data alongside Microsoft’s trusted AI platform. Microsoft is a sponsor at Oracle AI World 2026 — register now to reserve your seat and stop by booth #10028 to talk to experts and win prizes! Hear from Microsoft’s Brett Tanzer Four Clouds, One Conversation: OCI, AWS, Azure, and Google Leaders on What's Next [LRN1134] Join Microsoft Vice President Brett Tanzer for a four-cloud panel discussion exploring what’s next for multicloud data and AI, and why the decisions being made today will shape tomorrow’s cloud strategy. October 26 | 11:30AM Microsoft sessions you won't want to miss Monday, Oct 26 12:45 PM - 1:30 PM PDT Mission-Critical Modernization with Oracle Database@AnyCloud [LRN2573] See how Talcott Financial Group and Citizens Bank modernized mission-critical platforms on a secure, audit-ready multicloud foundation — Talcott moved 50+ databases and cut operational TCO by 70%. Tuesday, Oct 27 8:00 AM - 8:45 AM PDT From Oracle Data to AI Innovation with Oracle AI Database@Azure [LRN2247] See how Oracle AI Database@Azure connects Oracle data to Fabric, Foundry, Copilot, and AI agents without moving or rebuilding what works — p lus, hear directly from customers as they discuss their Azure journey, the decisions that shaped their transformation, and the results they’re achieving today. Tuesday, Oct 27 1:00 PM - 1:45 PM PDT Connected Agents Across the Enterprise, Built with Microsoft Foundry [LRN2274] See how the Agent2Agent (A2A) protocol connects Oracle Private Agent Factory and Microsoft Foundry so agents collaborate across cloud boundaries. Tuesday, Oct 27 1:50 PM - 2:10 PM PDT Build an AI Agent on Oracle Data with Microsoft AI in 20 Minutes [THR2275] What can you do in 20 minutes? Watch an Oracle workload go from migration to AI agent in a single demo, proving you don’t have to rearchitect to start putting enterprise data to work with AI. Check out additional sessions featuring Microsoft and Oracle product experts. Tuesday, Oct 27 1:00 PM - 1:45 PM PDT AI Without Cloud Boundaries: Autonomous AI Database on AWS, Azure, Google Cloud [LRN6082] Tuesday, Oct 27 2:15 PM - 3:00 PM PDT Breaking the Walled Garden: The Engineering Behind Oracle Database@Everywhere [LRN2423] Wednesday, Oct 28 1:40 PM - 2:00 PM PDT Oracle AI Database@Azure: Real-World Multicloud Patterns from an Oracle ACE [THR6094] Stop by the Microsoft booth (#10028) in the hub – where innovation meets fun! Connect with Microsoft and explore how Oracle AI Database@Azure can help accelerate your cloud strategy and unlock new possibilities with Microsoft AI. We're running live demos with our experts throughout the day, so come see the platform in action and bring the questions you can't get answered anywhere else. Enter our raffle for a chance to win– all while exploring the most innovative Azure solutions driving enterprise transformation.

Public Preview: Onboard Kubernetes Clusters to Azure Arc with the Multicloud Connector

Wed, 07 Oct 2026 13:59:49 +0000

Today we're announcing that the Azure Arc Multuicloud Connector Arc onboarding solution for Kubernetes clusters is in public preview for both Amazon EKS and Google GKE! With this release, the Multicloud Connector automatically discovers eligible EKS clusters in your connected AWS accounts and GKE clusters in your connected GCP projects and onboards them to Azure Arc-enabled Kubernetes - so you can see and govern them alongside your Azure and Arc-enabled resources. What's New When using the EKS Arc onboarding or GKE Arc onboarding solution, the Azure Arc Multicloud Connector: Discovers eligible EKS or GKE clusters across the source cloud regions you choose Represents them in Azure so they're visible alongside your Azure and Arc-enabled resources Installs the Azure Arc-enabled Kubernetes agents on the clusters you select Keeps syncing on a schedule you define, picking up new clusters as they appear No scripting or per-cluster onboarding required. Once a cluster is Arc-enabled, it becomes a first-class Azure resource. That unlocks the Azure management, governance, and security: Governance at scale with Azure Policy for Kubernetes, applied consistently across AKS, EKS, and GKE. Security posture and threat protection through Microsoft Defender for Cloud. Observability with Azure Monitor container insights. GitOps-based configuration and app deployment with Flux v2 and Arc-enabled Kubernetes extensions. A single inventory you can query with Azure Resource Graph - including metadata and tags carried over from the source cloud. What's in the preview Automatic discovery and onboarding: Enable the EKS or GKE Arc onboarding solution on a connected public cloud, and the connector scans your selected regions for eligible clusters, surfaces them in Azure, and installs the Azure Arc-enabled Kubernetes agents on the clusters you choose. Flexible connectivity: When you configure the solution, you can specify: HTTP/HTTPS proxy settings and proxy skip ranges An Azure Arc gateway resource, if you want Arc traffic to route through Arc gateway Periodic sync: Set a sync interval and the connector keeps working after day one. It evaluates newly discovered clusters against your onboarding criteria, retries clusters where onboarding previously failed, and keeps the Azure representation aligned with the source cloud as clusters come and go. You can also turn periodic sync off if you'd rather onboard on your own schedule. Scoping with filters: Filter eligible clusters by Source cloud region - choose exactly which AWS or GCP regions get scanned Source cloud tags or labels - AWS tags and GCP labels are both supported, and matching is case-insensitive Visibility into onboarding state: Discovered clusters show their connectivity status directly in the portal, so you can tell at a glance where things stand. Get Started Connect your cloud. Follow Add a public cloud with the multicloud connector to link your AWS account or GCP project and review prerequisites. Check readiness. Confirm your clusters meet the Arc-enabled Kubernetes system requirements , sit in a supported source-cloud region, and aren't already connected to Arc. Enable the solution. Use Onboard Amazon EKS and GKE clusters to Azure Arc for the full walkthrough - the page has separate tabs for AWS EKS and GCP GKE. Preview notes Both the EKS and GKE Arc onboarding solutions are in preview . A few things to know before you plan a rollout: Only EKS clusters in AWS and GKE clusters in GCP are supported today. Clusters already connected to Azure Arc should keep using their existing Arc-enabled Kubernetes resource - onboarding them again may create duplicate representations or fail. Individual Azure services for Arc-enabled Kubernetes carry their own regional and feature availability requirements. Preview features are governed by the Supplemental Terms of Use for Microsoft Azure Previews . Learn more What is Multicloud connector enabled by Azure Arc? Onboard Amazon EKS and GKE clusters to Azure Arc (preview) Add a public cloud with the multicloud connector View multicloud inventory Troubleshoot the multicloud connector Azure Arc-enabled Kubernetes overview

Sending From Email Aliases – General Availability

Wed, 07 Oct 2026 13:59:20 +0000

Today we are announcing the General Availability (GA) of Sending from Aliases for Exchange Online. This was a highly requested feature that now empowers users to send emails from any alias (proxy address) associated with their mailbox, not just their primary SMTP address. Read on to learn how it works, how to enable it, and what’s next. What Is Sending From Aliases? Sending from Aliases allows Exchange Online users to send emails using any of their configured aliases or proxy (or secondary) SMTP addresses. Previously, aliases could only receive mail, and all outgoing messages used the primary SMTP address of the mailbox. Workarounds like shared mailboxes or distribution groups were used in the absence of native alias sending support. With the Sending From Aliases feature, which until now has been in Public Preview , users can: Send from any alias directly using Outlook clients. Reply from aliases when an email was addressed to it. Select which aliases to display in supported clients. How Does It Work? Admin Setup Enable at the tenant level via PowerShell: Set-OrganizationConfig -SendFromAliasEnabled $True Or use the Exchange Admin Center: Go to Settings → Mail Flow → Turn On Sending from Aliases . Aliases for users are managed in the M365 Admin Center. Admin who wishes to block a domain from being able to send can set the domain as Receive Only in the M365 Admin Center. User Experience Outlook on the Web Go to Settings → Compose & Reply to view and select aliases Outlook Desktop (Windows/Mac) Use the From field dropdown or enter the alias manually Outlook Mobile Tap the From field to select from available aliases Replies automatically use the alias the message was sent to. Aliases are given to users for various reasons. If, for whatever reason, a user should not receive or send messages using a given alias, it is possible to set the entire domain to Send-only or Receive-only. To set a domain to Send-only or Receive-only, use the SendingFromDomainDisabled or SendingToDomainDisabled parameter of Set-Accepteddomain cmdlet from Exchange Online Powershell. More nuanced restrictions would need to be implemented with mail flow rules or organizational policies that users should follow. Known Gaps or Behavior Changes There are certain features that rely on the email address used to send or receive messages. Rules set up that do not account for aliases such as journaling or routing rules, may not work as expected. Other features may work with the mailbox identity and be unable to differentiate between aliases used. This feature is for Exchange Online-hosted mailboxes only. Messages to and from on-premises can be subject to rewriting the aliases on those servers. In Hybrid scenarios, when email is sent from on-premises to Exchange Online, email is sent to user’s mail.contoso.onmicrosoft.com address. With send-as-alias feature enabled, this address is preserved and not resolved to user’s primary address. This can cause issues like OOF response coming from user’s mail.contoso.onmicrosoft.com address instead of the email address representing user’s actual email domain name (contoso.com). Please raise a DCR with the Outlook team if your organization would like autoreply messages to avoid using mail.contoso.onmicrosoft.com addresses. For shared mailbox, send from alias feature works only with OWA when delegate opens it using “Open another mailbox” option. For Outlook client, send from alias feature is not supported for shared mailbox at all. Various types of rules in Exchange Online may look for specific email addresses and not match aliases, resulting in the rule not acting on a subset of messages from a given mailbox. Features with rules include hygiene, journaling, and mail flow rules. Message Trace queries using a primary SMTP address return results that do not include messages sent using an alias. To trace messages sent to or from an alias, you need to use the alias in your query. This is less of a known issue and more about highlighting the change to existing behavior. Some companies have set up Outlook clients with aliases or display names that differ from the user’s primary email address and display name stored on the mailbox. Different email addresses or display names may appear on messages when the feature is enabled. When the sending from aliases feature is enabled, it may cause a change in behavior for what shows up in sent messages’ From field. Future Enhancements While the GA release delivers the core functionality, we still plan to expand the feature set in future updates. GA is a major milestone for this important feature, and we want to show our commitment to supporting it and customers who choose to use it with this announcement. Additional functionality we’re investigating (but not necessarily committing to) includes: Display names per alias Additional filtering or default controls Calendar support Follow up communications will announce which features we plan to work on and deliver post-GA. Next Steps Admins who have not done so already can review and enable the feature for your organization using the guidance above. Please raise support tickets if you uncover any issues that you discover and are not called out in the Known Gaps section. This feature was a significant shift from the previous behavior of Exchange Online and edge cases may still exist. Monitor for announcements on future enhancements to the feature. Exchange Online Team

Inside Intune: Faster compliance updates for Windows devices

Wed, 07 Oct 2026 12:29:42 +0000

Microsoft has introduced client-driven compliance evaluation for Windows devices. The idea is simple. Instead of waiting for the next scheduled check-in, the device notices a change and asks Intune to […]

Update network rules for the API Management service tag

Wed, 07 Oct 2026 10:41:21 +0000

To improve Azure API Management resiliency and scalability, we’re expanding our infrastructure and adding control-plane IP addresses. These addresses are included in the ApiManagement service tag. If you use VNet internal or VNET external with the classic (v1) tiers , check your network security groups (NSGs), user-defined routes (UDRs), and firewalls. Replace hard-coded API Management IP addresses with the service tag wherever supported. Make this change by November 30, 2026, to avoid disruption to management access. If network rules block connectivity to the management endpoint after that date, you may be unable to manage your API Management configuration—such as APIs, operations, and policies—from the Azure portal or CLI. This change affects management-plane traffic only. Runtime traffic, including API calls to your services, is not impacted. Find the ApiManagement tag in Microsoft’s Azure service tags overview or the latest Azure IP Ranges and Service Tags JSON download . If your firewall doesn’t support service tags, use the published list and keep your IP rules synchronized with its latest version. Don’t rely on a fixed, point-in-time IP list. During the transition, the service tag includes both existing and new addresses. For reference: Use API Management in an internal virtual network

Interim guidance for Manitoba permanent DST 2026

Wed, 07 Oct 2026 09:47:55 +0000

On September 17, 2026, the Manitoba government made an official announcement about a Daylight-Saving Time (DST) time zone change. Starting at 02:00 a.m. November 1, 2026, the official time will not fall back by an hour and will permanently remain on the UTC-5 time zone. The impact of this change is as follows: Clocks will not be set back by an hour at 02:00 a.m. on November 01, 2026, for the Manitoba time zone. The Manitoba Region time zone will permanently remain on the UTC-5 time zone. Microsoft plans to release an update to support this change. However, we require sufficient time to properly build, test, and release such an update for all platforms before the change goes into effect. See How Windows manages time zone changes to better understand the complexities of this process. Release p lan The supported platforms will receive an update to support this time zone change as part of the October 2026 Windows security update, scheduled for October 13, 2026. For additional information, please review our official policy page and How Windows manages time zone changes . The following platforms will receive an update to support this time zone change as part of the October 2026 Windows security update: Windows 11, version 25H2 Windows 11, version 24H2 Windows Server 2025 Windows Server 2022 Windows Server 2019 Windows Server 2016 Customers must install the update before permanent time changes take effect on November 1 st , 2026. This Windows update introduces a new time zone: Affected area Name displayed in Windows Settings (New Time Zone) Registry time-zone ID Manitoba (UTC-05:00) Manitoba Manitoba Standard Time The registry time-zone IDs are intended primarily for administrators and command-line tools. Users normally see only the windows Settings display names. After installing the update, verify the selected time zone under: Settings > Time & language > Date & time Case #1 - Automatic time-zone selection If " Set time zone automatically" option is enabled and location services are available, Windows will automatically select the appropriate time zone based on the device's location. No manual action is required. It shall be reflecting as (UTC-05:00) Manitoba Windows display name. Case #2 - Manual time-zone selection If "Set time zone automatically" option is disabled, users must select the appropriate zone manually: Open Settings > Time & language > Date & time . Turn off Set time zone automatically , if it is enabled. Under Time zone , select the applicable Windows display name: (UTC-05:00) Manitoba for Manitoba. Confirm that the displayed date and time are correct. Interim g uidance when the update is unavailable Before the permanent time transition takes effect on November 1st, 2026, the existing seasonal zones continue to provide the expected current offset. In cases where the monthly update cannot be received or installed before 1 st of November, affected organizations with devices in Manitoba are advised to use the following workarounds: After November 1 st , 2026, we suggest using the below fixed-offset alternatives only as temporary workarounds: Affected area Existing choice before the transition Temporary choice after the transition Manitoba (UTC-06:00) Central Time (US & Canada) (Central Standard Time) (UTC-05:00) Eastern Time (US & Canada) (Eastern Standard Time) ¹ ¹ After switching to Eastern Time, disable "automatic DST adjustments" option to lock the offset at UTC-05:00. Go to Settings > Time & language > Date & time . → Select toggle " Adjust for daylight saving time automatically" to Off . Re-enable this setting once the October 2026 Windows security update with Manitoba Standard Time is installed. Note: Because Manitoba is on Central Daylight Time (CDT = UTC-05:00) through November 1st, users may apply the Eastern Time and disable DST workaround at any point before the transition. The offset will be correct both before and after the fact. These alternatives provide the required UTC offset but have different names, geographic mappings, and historical rules. They should not be treated as permanent replacements. We recommend installing the latest Windows monthly update and moving to the appropriate region-specific time zone as soon as possible.

Azure SQL Database is retiring Always Encrypted with Intel SGX enclaves

Wed, 07 Oct 2026 09:15:52 +0000

On October 31, 2027 , Azure SQL Database will retire Intel Software Guard Extensions (SGX) enclave functionality for Always Encrypted . Workloads that still depend on Intel SGX enclaves after that date will no longer work as configured. The path forward is Virtualization-Based Security (VBS) enclaves, a hardware-independent option that does not require attestation. To retain secure-enclave capabilities, move databases from DC-series compute to a supported standard-series, non-DC tier and update affected applications for VBS enclave mode. What is changing? Intel SGX enclaves are tied to DC-series compute. After October 31, 2027, databases on these tiers must move to supported compute to retain enclave-enabled capabilities. Applications configured for Intel SGX enclaves may also need driver and connection-string updates. For workloads that do not require isolation from the host operating system, VBS enclaves offer a straightforward migration within Azure SQL Database. If your threat model requires Intel SGX-equivalent host isolation, evaluate SQL Server on Azure Confidential VMs instead. Choose the right migration path Use the migration guide to identify databases and elastic pools on DC-series compute, choose the target architecture that matches your threat model, update application connectivity and attestation settings, and validate the workload before production cutover. Move to VBS enclaves in Azure SQL Database Choose VBS enclaves when you need to protect sensitive data from unauthorized users or malicious insiders but do not require isolation from the host operating system. VBS enclaves run on supported non-DC compute tiers and eliminate attestation requirements. Consider SQL Server on Azure Confidential VMs If your threat model requires stronger isolation from the host operating system, assess SQL Server on Azure Confidential VMs. Compare architecture, operations, compatibility, and cost with the Azure SQL Database option. Start planning early Start now. Discovery, compute-tier changes, application updates, security review, and production validation all take time. Complete the migration before October 31, 2027, to keep enclave-enabled workloads running without interruption. Help and support Have questions? Ask community experts in Microsoft Q&A . If you have an Azure support plan and need technical help, create a support request . Review service retirements that may affect your resources in the Azure Retirement Workbook . For more ways to find impacted resources, see the retirement guidance . Retirement information may take up to two weeks to appear.

Bulk changing blob tiers using Azure Storage Actions

Wed, 07 Oct 2026 08:13:05 +0000

Managing blob access tiers at scale can be challenging, especially when a storage account contains a large number of blobs spread across containers and virtual directories. Traditionally, changing blob tiers in bulk may require scripts, automation runbooks, or custom tooling to iterate through each blob and update its access tier individually. Azure Storage Actions provide a no-code way to perform bulk operations on blobs based on defined conditions. This makes it easier to move blobs between tiers such as Hot, Cool, Cold, or Archive without writing custom scripts. In this blog, we present a no-code solution for bulk changing blob access tiers using Azure Storage Actions. This approach is especially useful when dealing with a large number of blobs, eliminating the need for custom scripts. Additionally, it allows you to apply multiple filters so that only the required blobs are moved to the intended tier. Azure Storage Actions offer an efficient solution for changing blob access tiers in bulk. Below are the steps to use this feature effectively: Search for Azure Storage Actions in the Azure portal. Search for Azure Storage Actions in the Azure portal. On the left menu , select Storage Tasks . Click + Create . Open Storage Tasks and start creating a new storage task. Select the subscription where the target Storage Account is located. Select or create a resource group . Enter a Storage task name. Select the same region as the target Storage Account. Configure the basic project and instance details. Click Next > to continue. Configure the condition and operation Using the Visual builder in the If section: Set the Blob property to Access tier . Set the operator to target the required source tier, such as Equals or Not equal to . Set the Property value to the source tier you want to target, such as Hot , Cool , Cold , or Archive . In the Then section: Set the Operation to Set blob tier . Set the target tier to the desired value, such as Cool . Click Next > to continue. Example: To move all blobs that are not already in the Cool tier, configure the condition as Access tier Not equal to Cool and set the operation to Set blob tier = Cool . Configure the visual builder to target blobs by access tier and set the destination tier. Add the assignment In the Assignments tab, click + Add Assignment . Add an assignment for the storage task. In the Add Assignment blade: Select the Subscription where the target Storage Account is located. Select the target Storage Account . Provide an assignment name. Select the role to be Storage Blob Data Owner , or any role that grants the required access to blobs and tags. NOTE: Full access to blobs only may result in a 403 error. If filtering the blobs to update, select Blob prefix and enter a prefix that starts from the container name onward. Otherwise, select Do not filter . Select Single run (only once) as the Run frequency . Select or create a container for the Report export container . Click Add to finish the assignment creation. Configure assignment scope, permissions, filtering, trigger details, and report export. Back in the Assignments tab, click Next > to continue. Continue from the assignment configuration. Add tags if needed. Click Next > to continue. Click Review + create to create the Storage Task. Review and create the storage task. This will redirect to the Deployment blade. Wait for deployment to be completed. Click Go to resource to navigate to the Storage Action overview. Open the created storage task after deployment completes. Run the storage task In the left menu, click Assignments . Select the assignment that was created and click Enable to begin changing blob tiers. Enable the assignment to start the storage task run. Once the task runs and completes, the selected blobs should have their access tier changed according to the conditions and target tier selected. You can also access execution reports for the storage task, which provide detailed insights into the operation performed on each targeted object. For more information on execution reports, refer to Analyze storage task runs - Azure Storage Actions Preview | Microsoft Learn . Yes, I think the blog is in good shape to publish. The main thing I would add is a cost consideration/warning immediately before the “Run the storage task” section , because that is the point where enabling the assignment can trigger changes across many blobs. Cost considerations Before running a storage task that changes blob access tiers at scale, consider the potential cost implications. While moving data to cooler tiers can reduce storage costs, tier changes can incur transaction charges, data retrieval charges in certain scenarios, and early deletion charges if blobs are moved or deleted before the minimum retention period for their current tier has elapsed. This is particularly important when moving large amounts of data or working with the Archive tier, where rehydration also has associated costs. Before enabling the assignment, review the scope and filters carefully and estimate the expected cost impact. For more information, see Access tiers for blob data - Azure Storage | Microsoft Learn and Plan and manage costs for Azure Blob Storage | Microsoft Learn Conclusion Azure Storage Actions provides a simple and efficient way to change blob access tiers in bulk without writing scripts or managing custom automation. By using conditions such as the current access tier, blob prefix, or other supported filters, you can target only the blobs that need to be updated and apply the desired tier at scale.

Tech in Five - What is MCP?

Wed, 07 Oct 2026 07:58:31 +0000

An overview of what MCP is and why its so useful. 🔎 Looking for content on a particular topic? Search the channel. If I have something it will be there! 🤔 Due to the channel growth and number of people wanting help I no longer can answer or even read questions and they will just stay in the moderation queue never to be seen so please post questions to other sites like Reddit, Microsoft Community Hub etc. ▬▬▬▬▬▬ C H A P T E R S ⏰ ▬▬▬▬▬▬ 00:00 - Introduction 00:08 - Integration challenges with AI 01:05 - What can a target service do? 01:24 - MCP, the USB-C for AI 02:13 - Capability discovery 03:15 - MCP Server capabilities 05:03 - Local or remote MCP Server 06:20 - What does MCP change 07:15 - Close ▬▬▬▬▬▬ Want to learn more? 🚀 ▬▬▬▬▬▬ 📖 Recommended Learning Path for Azure 🔗 https://learn.onboardtoazure.com 🥇 Certification Content Repository 🔗 https://github.com/johnthebrit/CertificationMaterials 📅 Weekly Azure Update 🔗 https://youtube.com/playlist?list=PLlVtbbG169nEv7jSfOVmQGRp9wAoAM0Ks ☁ Azure Master Class 🔗 https://youtube.com/playlist?list=PLlVtbbG169nGccbp8VSpAozu3w9xSQJoY ⚙ DevOps Master Class 🔗 https://youtube.com/playlist?list=PLlVtbbG169nFr8RzQ4GIxUEznpNR53ERq 💻 PowerShell Master Class 🔗 https://youtube.com/playlist?list=PLlVtbbG169nFq_hR7FcMYg32xsSAObuq8 🎓 Certification Cram Videos 🔗 https://youtube.com/playlist?list=PLlVtbbG169nHz2qfLvPsAz9CnnXofhmcA 🧠 Mentoring Content 🔗 https://youtube.com/playlist?list=PLlVtbbG169nGHxNkSWB0PjzZHwZ0BkXZZ ❔ Questions? Maybe I answered it in my FAQ 🔗 https://savilltech.com/faq 👕 Cure Childhood Cancer Charity T-Shirt Channel Store 🔗 https://johns-t-shirts-store.creator-spring.com/ 👂 Enable the subtitles and from there you can translate to your native language via the auto-translate feature in settings! https://youtu.be/v5b53-PgEmI for a demo of using this feature. SUBSCRIBE ✅ https://www.youtube.com/channel/UCpIn7ox7j7bH_OFj7tYouOQ?sub_confirmation=1 #AI #MCP #TechinFive #johnsavillstechnicaltraining #cloud

What is actually in your Power Platform estate, and what it would cost to fix.

Wed, 07 Oct 2026 07:50:42 +0000

An open-source analyzer that reads your Power Platform or Dynamics 365 environment, prices its technical debt in ranges and turns it into a backlog. It never writes to the environment, names every check it could not run, and checks whether your contact centre can get a conversation to a person.

Streaming Grounded Chat to Desktop and Mobile Through a Rust Bridge

Wed, 07 Oct 2026 07:00:00 +0000

A streamed answer feels simple until two conversations run at once, the user changes screens, a token begins with a space, or the user presses Stop before the HTTP request has fully started. Add a bearer token and health-record context, and the transport boundary becomes part of the security and correctness design - not merely UI plumbing. Part 6 follows one grounded answer from the Desktop App or Mobile App through a Tauri v2 Rust bridge, into a Rocket server, through local retrieval and Foundry Local , and back as correlated events. The pattern keeps the JWT, base URL, HTTP client, and SSE stream outside the web view while supporting concurrent runs, per-conversation queues, cancellation, bounded server memory, citations, and optional verification. The transport boundary is also where a residency obligation is most easily undone. Where a country requires processing connected to primary or secondary health care to be carried out through a server and data centre inside its borders - Kenya, the setting of the research behind this series, is one - a phone in a ward does not breach that, provided the server it talks to stays inside the facility and the answer is assembled there. But a web view holding the JWT and calling out directly, a crash reporter that ships prompt text, or an analytics SDK bundled into the client would each move record content offsite. Keeping credentials, HTTP, and the SSE stream in the Rust bridge is what keeps the client a rendering surface rather than a second egress point. Part 1 sets out the boundary. This is a prototype using synthetic health data. It is not compliance or clinical guidance, and the Mobile App is initialized and configured but not production-device validated. This series implements the pattern in Rust, but it can use the Foundry Local SDK Reference with C#, JavaScript, Python, or Rust; Part 2 lists the language-specific links. Problem statement A chat UI becomes unsafe and inconsistent when its web layer holds a bearer token, calls the server directly, or treats all streaming work as one global loading state. Concurrent conversations, navigation, cancellation, and partial responses then compete for shared listeners and mutable state. SSE adds protocol-specific risks: leading whitespace can be lost, listeners can outlive screens, and late events can update the wrong conversation. If the client also supplies authoritative history, a modified Desktop App or Mobile App can inject memory that the server never persisted or authorized. The chat transport must put credentials and networking behind the Tauri Rust bridge, correlate every event to an isolated run, and let request lifetime survive navigation without leaking listeners. The Rocket server must own conversation memory and evidence, while cancellation and partial failures remain explicit to the client. No part of that path - request, stream, log, or crash report - may terminate outside the facility. Success criteria The web view never stores the JWT or makes direct authenticated API calls. Every stream event is correlated to one run and one conversation. Concurrent runs, navigation, and cancellation cannot cross-update state. SSE token framing preserves whitespace and typed payload boundaries. The server authorizes and assembles bounded conversation memory. Partial output is distinguishable from a committed assistant message. Put transport and credentials in the Rust bridge The Desktop App and Mobile App share a Tauri shell and web-view implementation. The web layer renders the experience and manages presentation state. It does not call the server directly and never owns the JWT. The local Rust bridge owns: the configured server base URL; the bearer JWT; the reqwest client; authenticated REST requests; SSE consumption; per-run abort handles; and translation from server events to typed Tauri events. External PostgreSQL, MySQL, and SQL Server databases are not shown on the hot semantic-chat path. They are grouped as External Clinical Databases elsewhere in the architecture and feed the internal store through ingestion or serve separately guarded live SQL. The Internal DocumentDB Hybrid Store is not one of those sources. The bridge boundary reduces accidental exposure: a component cannot read a token from browser storage or quietly invent a direct API call. It is not complete hardening, however. The current bridge persists the token in a plugin store rather than an OS secure credential store, and development transport defaults to HTTP. Production PHI deployment still requires TLS, approved certificates, least-privilege Tauri capabilities, CSP review, and secure device storage. Stage 1: create a run, not a global “loading” flag A single isStreaming boolean fails as soon as users can switch conversations. The client runtime instead generates a UUID for each submission and creates a run record containing its conversation, prompt, options, phase, partial answer, citations, structured data, and error state. const runId = crypto.randomUUID(); addActive(activeChatRuns, conversationId, runId); useChat.getState().startRun(runId, conversationId, prompt, options); try { await chat(prompt, [], options, conversationId, runId); await queryClient.invalidateQueries({ queryKey: ['messages', conversationId] }); } finally { removeActive(activeChatRuns, conversationId, runId); startNextChat(conversationId); } Independent conversations can run concurrently. Within one conversation, normal prompts queue behind active work. A deliberate Send now action bypasses that queue, with an explicit consequence: the unfinished answer is not yet part of server-loaded history, so the new run may not see it. Navigation does not own the request lifetime. An app-level conversation runtime does. Switching tabs or conversations therefore cannot orphan the stream. Rename and delete are blocked only where active work makes them unsafe; the rest of the application remains usable. Stage 2: load server-owned working memory When a conversation_id is present, the Rocket server verifies that the JWT subject owns it. It persists the user turn before answer generation, then assembles bounded working memory from DocumentDB: an optional rolling summary of older messages; and a chronological verbatim tail bounded by turn count and approximate word budget. Long assistant turns are clipped before entering memory. The summary becomes a synthetic leading turn for query rewrite, while summary and tail can provide continuity to generation. They are not citable evidence . After a successful assistant turn, write-behind compaction can fold older overflow into a concise local-model summary. Compare-and-swap on summary_upto prevents two overlapping compactions from interleaving. A database or summarization failure does not block the visible answer; later turns retain the bounded tail and can retry compaction. This makes DocumentDB the authoritative transcript. PHI-bearing drafts and active buffers remain in client session memory rather than browser persistence. Stage 3: choose the answer path before streaming tokens The server’s tiered router chooses among conversational, conversation-meta, structured SQL, constrained DocumentDB aggregation, hybrid classification, and semantic retrieval. The semantic path from Part 5 performs rewrite and expansion, BGE-M3 embeddings, concurrent vector and lexical search, RRF, row dedupe, reranking, and a relevance gate. If the gate rejects a pointed query, the server emits an explicit no-relevant-records answer instead of opening ungrounded generation. If evidence is accepted, a bounded prompt contains numbered retrieved passages. Only those passages may be cited. Foundry Local then opens a local streaming chat completion. In this project the Rust server embeds the native SDK in process; there is no separate model HTTP endpoint and no cloud-model fallback. Missing local inference degrades explicitly rather than sending sensitive prompts elsewhere. The server persists a successful assistant turn only after generation completes. A mid-stream failure can therefore leave the already-persisted user message without an assistant record. The client preserves partial visible output for retry, but it must not present that partial output as a committed transcript entry. Stage 4: treat SSE as a framed protocol The server emits typed events rather than one undifferentiated byte stream. Depending on the selected path, a chat run can carry: routed for the route decision; citations for semantic evidence; sql, columns, and rows for live-source results; token for visible answer fragments; verify for a post-stream report; error; and done. A subtle but important detail is token encoding. A bare SSE line such as data: word can lose leading whitespace during parsing and fuse streamed words. The server JSON-encodes each token: fn token_event(text: &str) -> Event { let data = serde_json::to_string(text) .unwrap_or_else(|_| "\"\"".to_string()); Event::data(data).event("token") } The bridge decodes that JSON string before emitting chat://token. Structured payloads remain JSON text until the typed frontend listener parses them. The planned event order The service-line design in plan 04 and plan 06 fixes one event order shared by /chat and every /agents/ route, because both are meant to call the same structured executor: routed → [clarify] → sql, columns, rows (live source SQL) | spec, rows, pipeline (constrained DocumentDB aggregation) | citations (semantic passages) → provenance → token* → [verify] → [suggestions] → done | error Three things change relative to today’s stream. routed gains service_line, deterministic, and focus_used, so the client can label the answering department, mark answers that never touched a model planner, and show which remembered entities were substituted into the question. A clarify event may replace the evidence block entirely when the router is confident the question is structured but a required slot is unbound; it carries one question and a short option list, and the design allows at most one clarification per turn. And provenance becomes a first-class event that precedes the first token: an ordered list of rungs actually attempted - link, deterministic SQL, model SQL, validate, execute, aggregation, list, retrieval - each marked hit, miss with a PHI-free reason, or skipped, plus the backend used, the scope, and per-rung timings. Today the client infers provenance from which events happened to arrive; the planned contract states it. The bridge relays the new events under the existing envelope as agent://provenance, agent://suggestions, and agent://clarify (with chat://* equivalents) and passes routed through unchanged. Each new field is also persisted on the assistant message, so a reloaded conversation shows the same provenance and suggestions the live stream did. None of this order is implemented yet; the current stream is the bullet list above. The bridge stamps every event with the client-generated run ID: #[derive(Serialize, Clone)] struct ChatEvent { run_id: String, data: String, } app.emit( "chat://token", ChatEvent { run_id: run_id.clone(), data: decode_token(&event.data), }, )?; Without the envelope, two simultaneous streams can interleave in one answer. Channel names identify event kinds; run IDs identify instances. Stage 5: register listeners once at boot Per-component listeners are tempting: mount a chat view, subscribe, and unsubscribe on navigation. That pattern leaks under hot reload, misses events when a route unmounts, and makes concurrent routing fragile. The application instead installs one listener for each long-lived channel at boot. Each listener checks the run ID, then fans the event into a Zustand store. Token bursts are buffered per run and flushed on animation frames: const tokenBuffer = createKeyedRafBuffer((runId, batch) => { useChat.getState().appendAnswer(runId, batch); }); await listen('chat://token', ({ payload }) => { if (useChat.getState().runs[payload.run_id]) { tokenBuffer.push(payload.run_id, payload.data); } }); await listen('chat://done', ({ payload }) => { tokenBuffer.flushNow(payload.run_id); useChat.getState().finish(payload.run_id); }); Per-run buffering prevents simultaneous answers from sharing a frame batch. Flushing before terminal state prevents the final token fragment from arriving after the UI marks the run complete. The same global-listener pattern handles agent runs, ingestion progress, model downloads, and logs, using run_id, job_id, or variant_id as the appropriate correlation key. Stage 6: cancellation must handle races The bridge creates an abort handle before beginning the request and registers it under the run ID. cancel_run removes and aborts that handle. Logout aborts every active run before clearing session state. There is also a narrow race: the user can press Stop before the invocation has registered its handle. The bridge keeps a bounded, time-limited cancelled_before_start map. When the late registration arrives, it is aborted immediately rather than resurrecting a stopped request. pub fn register_run(&self, id: String, handle: AbortHandle) { let mut runs = self.active_runs.lock().expect("run registry poisoned"); if runs.cancelled_before_start.remove(&id).is_some() { handle.abort(); } else { runs.active.insert(id, handle); } } The map has a TTL and maximum size, preventing malicious or accidental unknown IDs from growing memory indefinitely. Cancellation currently drops the bridge-side HTTP/SSE stream. That is useful and visible, but complete propagation through already-running server retrieval, SQL, blocking embedding, or native generation is not proven. Documentation should distinguish “the client stopped receiving” from “all server computation terminated immediately.” Stage 7: persist evidence and verify the exact message For semantic answers, citations are emitted before tokens and persisted with the assistant message. For live SQL, the source ID, validated SQL, columns, and exact rows are retained. For constrained DocumentDB aggregation, the specification, rows, and generated pipeline are retained. The evidence type follows the route instead of being flattened into prose. Optional verification runs after streaming. Deterministic logic detects citation numbers outside the supplied range. A local verifier can then assess factual claims against the numbered passages. The report is persisted against the exact assistant-message ID, avoiding an unsafe “update the latest message” race when runs overlap. Verification adds a signal, not a guarantee. It is off by default, can be skipped on timeout or malformed output, and does not retract text already displayed. Planned: agents as service lines, and the UI that shows the evidence The current agent tabs - auto, health_query, trends, patient_lookup, summarize, chat - are hardcoded in the web layer and named after techniques . The design in plans/new reframes them as hospital service lines : Ask, plus Patient Chart, Front Desk, Ward Board, Emergency, Maternity, Theatre, Pharmacy, Diagnostics, Revenue, Quality & Safety, Workforce, Chronic Care, and Facilities. Each line owns a set of hospital concepts; which physical tables it can read comes from the per-source schema binding, not from code. Every line offers the same three modes - Ask, Trends, and Handover - as a toggle rather than as separate tabs. Existing persisted conversations keep working through a server-side mapping of the legacy kinds onto Ask. That changes what the client must render (plan 07 - app restructure): Registry-driven tabs. The tab bar is built from GET /agents, which returns each line’s label, tier, whether it is usable on the connected sources, its modes, its table scope per source, and example questions. Unusable lines are hidden or greyed; no service-line slug or label is a string literal in the web layer. The bridge’s agent kind becomes an opaque string validated server-side so a new line never needs a bridge rebuild. Scope panel. The side panel shows the agent’s blurb and “data this agent can see” as table chips grouped by source, drawn from the same registry payload. Provenance strip. A compact rung list under each assistant bubble - Link ✓ → Deterministic SQL ✓ → Validate ✓ → Execute ✓ · 212 ms - with misses showing their PHI-free reason on hover, and an expansion revealing the SQL and explanation, the aggregation spec and pipeline, or the retrieval filter as appropriate. Suggestion chips. Up to four follow-ups under the last assistant message only. They are generated by code from a mutated query specification that already binds, so clicking one should never produce a clarify or a miss. A click is a normal turn: the text is persisted as the user message, and the pre-parsed spec travels alongside so the router can skip parsing. Clarify blocks. The clarify question renders with its options as buttons that submit the option as the next prompt; a free-text reply works too. Focus and mode badges. A small “using: patient · period” chip when focus_used is non-empty, and the mode badge on each answer. Draft and conversation continuity are part of the contract, not polish. Switching tabs never discards the composer draft; drafts are keyed by conversation, or by kind for a not-yet-created one. Re-entering a tab restores its last open conversation. A conversation can move between agents (“Open in Maternity”) and its focus and history travel with it, with each bubble badged by the agent that answered. Today setSelectedKind resets the active conversation; the planned store keeps it. All of this is design direction. The mirrored-contract rule from the tradeoffs below applies with more force, because the number of fields the bridge and TypeScript must carry roughly doubles. Tradeoffs and anti-patterns The bridge adds code and mirrored contracts. Every new response field or event must be represented in Rust and TypeScript or it can disappear silently. That duplication is preferable to letting the web view own credentials and arbitrary networking, but it requires contract tests and disciplined updates. Avoid these anti-patterns: storing the JWT in ordinary web storage; calling the server directly from React components; registering stream listeners per component or per request; using one global partial-answer string; emitting unencoded SSE token text; treating route navigation as cancellation; persisting an assistant turn before its stream succeeds; updating “the latest” message when concurrent runs exist; claiming cancellation interrupts every native stage without evidence. Prototype status Implemented: Desktop App flow; shared Mobile App codebase and Android project; bridge-owned base URL, JWT, HTTP, and SSE; JSON token events; boot-time listeners; per-run registries; per-conversation queues; Send now; retry; bridge cancellation; logout-wide abort; server-owned summary-plus-tail memory; grounded citations; local Foundry Local generation; and optional post-stream verification. Partial: Mobile App device validation, secure OS-backed token storage, production TLS/certificate posture, CSP/capability hardening, and end-to-end cancellation through all server/native work. Not started: the service-line agent registry, provenance/suggestions/clarify events, and the UI elements described above. Tests use synthetic health records and do not establish clinical correctness or regulatory compliance. Key takeaways Make the Rust bridge the credential and transport boundary. Correlate every stream event with a run ID. Own request lifetimes above route components and queue per conversation. JSON-encode SSE tokens to preserve whitespace. Register global listeners once and batch tokens independently per run. Persist only successful assistant turns with their exact evidence. Describe cancellation and Mobile App readiness no more strongly than validated behavior. Continue the series Previous: Part 5 - A local hybrid retrieval pattern Next: Part 7 - Deterministic SQL before local LLM planning Learn more on Microsoft Learn What is Foundry Local? Get started with Foundry Local Foundry Local SDK Reference - Rust on Windows Design and develop a RAG solution The code behind this series is open source: github.com/kevin-gatimu/onprem-health-rag . It is a synthetic-data research prototype, not a clinical or compliance-ready system - issues and corrections are welcome.

From discovery to decision: A connected way to buy in Microsoft Marketplace

Wed, 07 Oct 2026 04:58:33 +0000

When I talk with customers about technology decisions, one thing is clear: finding a promising solution is only the beginning. The real work is deciding whether that solution solves the business need. Can I understand my options quickly? How does one solution compare with another? Can my team try it before making a decision? And when we’re ready to move forward, can the purchase reflect the way our organization actually needs to buy? Those questions become even more important as organizations bring cloud and AI solutions into more workflows and evaluate a growing range of options. That’s why I’m excited about the latest enhancements to Microsoft Marketplace. They help customers to find, evaluate, and choose the cloud solutions, AI apps, and agents that best fit their needs. Start with what you’re trying to accomplish Technology searches don’t always begin with a product name. Often, you know the business outcome or technical scenario you’re trying to address, but you don’t yet know which solution will get you there. You may be looking for an agent that supports a particular workflow, a solution for an industry scenario, or simply a better way to explore the options available to you. This is where intelligent discovery changes the starting point. With smart search in Microsoft Marketplace, you can describe what you’re looking for in natural language. Marketplace uses that input to refine the search and help identify relevant solutions. I think about this as moving from “What should I search for?” toward “Here’s what I’m trying to do.” Once you begin finding potential solutions, the evaluation becomes more specific. You can compare up to three offerings side by side and add your own criteria to the comparison. That matters because every organization evaluates technology differently. The questions that matter to your developers may be different from the questions procurement or business leaders need answered. Interactive chat extends that approach to individual product pages. You can ask questions in natural language about the solution you’re viewing, giving you another way to find the information relevant to your evaluation without relying solely on navigating through each section of the listing. Together, these experiences create a more natural progression: start with your need, explore possible solutions, compare your options, and dig deeper where it matters. Evaluation becomes more meaningful when you can try the solution There’s a point in many technology decisions when research needs to become hands-on evaluation. You’ve learned about the solution. You’ve compared the options. Now you want to understand what it could mean for your organization. Free trials in Microsoft Marketplace help bring that evaluation into the same journey. Solutions with free trials are easy to identify through search, filters, and free trial badges. You can search for free trials or use the Free trial pricing filter to focus on solutions that offer one. Once a trial is underway, you can track its status and see the number of days remaining in the trial period through Azure portal or the Microsoft 365 admin portal, depending on where the solution is managed. If the evaluation confirms that the solution is right for you, you can move to a paid subscription at public pricing at any point during the trial without reinstalling the solution. If it isn’t the right fit, you can cancel before the trial ends. This is one of the changes I find especially useful because a trial becomes part of the evaluation journey itself. You can move from discovering and researching a solution into actually trying it, while retaining visibility into where you are in the trial. The right solution also needs the right commercial structure Technical fit is important, but it isn’t the only consideration. Once a team decides that a solution meets its requirements, the conversation often shifts. How long do we need it? How should the agreement be structured? Does a standard term fit the project we’re planning? This is where we’ve expanded the flexibility available through private offers in Microsoft Marketplace. Custom contract lengths can range from one month to 10 years for supported private offer scenarios. That means an agreement can be structured around a six-month requirement, an 18-month engagement, a multiyear deployment, or another duration appropriate to the customer and partner agreement. There is flexibility in billing as well, including monthly or one-time payment options and annual billing when the term is annual. Custom contract duration is available for SaaS and professional services through private offers. I see this as an important connection between technical planning and purchasing. A proof of concept doesn’t necessarily have the same commercial requirements as a long-term deployment. Providing more flexibility in contract duration can help the commercial agreement better reflect the scenario being planned. Sometimes the next step is simply starting a conversation Not every purchase can be represented by a standard offer. A customer may want to discuss customized pricing, different terms, or specific solution requirements with the publisher. Rather than treating that conversation completely separate from discovery, customers can now initiate it from supported Marketplace listings. With the ability to request a private offer, customers can share their contact information and details about what they’re looking for directly from the listing. The request is delivered to the publisher as a Marketplace lead, creating a clear starting point for the customer and partner to discuss the opportunity. Requesting a private offer is available for SaaS and professional services offers, as well as compute offers including virtual machines, Azure applications, and containers. It’s a relatively simple step, but I think it represents something bigger about the purchasing journey. Discovering a solution, evaluating it, and discussing how to buy it don’t need to feel like unrelated activities. Think of evaluation as a journey, not a search That’s my biggest takeaway from these updates. Searching is one moment in a much broader decision process. You are able to start by describing what you need using Smart Search. From there, you can narrow your options, compare up to three offerings, and ask more detailed questions about an individual solution. When a free trial is available, you can move from researching the solution to experiencing it. And once you’re ready to discuss purchasing, private offers can provide additional flexibility around commercial requirements. For me, the common thread is decision-making with more context at each step. As you evaluate your next solution, I’d keep a few questions in mind: What problem or technical scenario am I actually trying to address? What criteria matters most to the people who will build with, manage, or use this solution? Is a free trial available if we want to validate the fit? What contract duration and purchasing structure are available to reflect the way we plan to use it? Do we need to start a private offer conversation with the publisher? You don’t have to answer all of those questions at once. But thinking about them as parts of one journey can help connect technical evaluation with the eventual purchasing decision. Watch the Microsoft Marketplace customer office hour There’s more to explore than I can cover in a single post. In our Microsoft Marketplace customer office hour, we demonstrate intelligent discovery, smart search, solution comparison, interactive chat, free trials, custom contract lengths, and the ability to request a private offer. We also answer questions about moving from trials to paid subscriptions, finding trial offerings, comparing solutions, and working with private offers. If you’re evaluating cloud and AI solutions, I encourage you to watch the full session on demand at aka.ms/MarketplaceCustomerOfficeHours . And I’d love for the conversation to continue here in the Microsoft Marketplace Community. What are you evaluating today? What would help you make your next technology decision with greater confidence? Share your questions and scenarios with us. They can help shape the conversations we have in future customer office hours.

Cybersecurity Mittendrin - Folge 30 - KI-Prompts im Live-System testen? Der sichere Weg in den Ruin!

Wed, 07 Oct 2026 03:00:23 +0000

Live-Tests in der Cybersecurity klingen nach einer guten Idee – bis das System crasht oder die KI unkontrolliert Daten leakt. 💥 Links: https://github.com/tomwechsler/Online_Workshops https://github.com/tomwechsler/Online_Workshops/blob/main/Cybersecurity_f%C3%BCr_KMU_Praxisorientierter_Einstieg/Readme.md https://github.com/tomwechsler/Cyber_and_Information_Security_Knowledge_Base In Folge 30 von Cybersecurity Mittendrin sprechen wir darüber, warum Live-Pentests und unüberlegte KI-Prompt-Tests (wie Prompt Injections) ein unkalkulierbares Risiko für Ihre Firmen-IT sind. Wer direkt in der Produktivumgebung testet, riskiert den Totalausfall. Die Lösung? Ein isoliertes Security Lab. Erfahren Sie in dieser Folge, wie Sie KI-Modelle, Prompts und IT-Infrastrukturen ohne Risiko auf Herz und Nieren prüfen und Ihre Systeme absolut sicher halten. #CybersecurityMittendrin #Pentesting #KIPrompts

Azure AD Graph API retirement: action required for older versions of Azure CLI and Azure PowerShell

Wed, 07 Oct 2026 02:00:01 +0000

Summary Azure AD Graph API (the legacy graph.windows.net API, not to be confused with Microsoft Graph) entered its retirement process in September 2024 , with the general shutdown completed on July 1, 2025 . Azure CLI and Azure PowerShell completed their migration away from Azure AD Graph well ahead of that deadline. az ad and the Az module's Microsoft Entra ID (Azure AD) cmdlets have been backed by Microsoft Graph for some time now. If you're running a current version of Azure CLI or Azure PowerShell, no action is required on your part for this specific retirement. Because Azure CLI and Azure PowerShell are Microsoft first-party clients, their Azure AD Graph application identities have remained available temporarily to provide a transition path for legacy releases that still call Azure AD Graph. However, those legacy releases have long been out of maintenance and are no longer supported; the temporary availability of the application identities does not mean the old releases remain supported. Beginning after October 6, 2026 , the Microsoft Entra team will progressively disable this remaining legacy access over a two-month buffer period. Users of current versions are not affected, but anyone still running an old release should upgrade now. This post explains what changed, why, and how to confirm you're unaffected. Terminology This post uses the following terms: Azure AD Graph API (https://graph.windows.net) — the legacy , now-retired API for reading and writing Microsoft Entra ID (formerly Azure Active Directory) objects: users, groups, applications, service principals, and directory roles. Microsoft Graph (https://graph.microsoft.com) — Microsoft's current, unified API surface for Entra ID and the broader Microsoft 365 ecosystem, and the only supported path going forward for any identity/directory operation. If your Azure CLI or Azure PowerShell still uses legacy Azure AD Graph, migrate as soon as possible Azure CLI has used Microsoft Graph for az ad commands since version 2.37.0 , and the identity-related cmdlets in Azure PowerShell have used Microsoft Graph since Az.Resources version 5.1.0 . These migrations were completed years before the Azure AD Graph retirement. Azure CLI releases earlier than 2.37.0 and Az.Resources releases earlier than 5.1.0 have long been out of maintenance and are no longer supported. The temporary availability of the tools' first-party Azure AD Graph application identities was retained only to provide a transition path for those legacy releases; it does not mean that the releases are maintained or supported. We are notifying users who still use legacy Azure AD Graph versions We are sending notifications in phases to tenants where telemetry indicates that calls may still be reaching Azure AD Graph endpoints. Some of this traffic comes from legacy Azure CLI or Azure PowerShell releases using the tools' temporarily retained first-party Azure AD Graph identities; other cases typically trace back to one of the following: An old, unsupported version of Azure CLI or the Az/AzureAD/MSOnline PowerShell modules still in use (for example, pinned in a long-lived CI/CD image or automation runbook that hadn't been updated). Custom scripts or tooling calling the legacy graph.windows.net endpoint directly via Invoke-RestMethod /curl/a hand-rolled SDK client, independent of az/Az entirely. The standalone legacy AzureAD or MSOnline PowerShell modules (distinct from the Az module), which were already deprecated separately from this effort and have their own migration path to Microsoft.Graph PowerShell cmdlets. These notifications are intended to help close out any remaining migration gaps and continue the original retirement communication. Beginning after October 6, 2026 , the Microsoft Entra team will progressively disable the remaining legacy first-party access over a two-month buffer period. Old Azure CLI or Azure PowerShell releases that still depend on Azure AD Graph may stop working at any point during this phased shutdown. How to check whether your automation still uses Azure AD Graph Checking the version actually running in each environment is the most reliable way to identify legacy Azure CLI or Azure PowerShell usage. Check developer machines as well as CI/CD agents, automation runbooks, scheduled jobs, and container images, which often remain pinned to an older version after interactive environments have been updated. You may need to work with your tenant, subscription, infrastructure, or automation administrators to locate the system that is generating the legacy traffic. The source may be a developer machine, VM, self-hosted build agent, automation worker, scheduled task, or container host that you do not manage directly. Use the tenant information from any targeted notification together with your organization's sign-in logs, automation inventory, pipeline logs, and VM or container inventory to identify the execution environment, then upgrade it or stop the obsolete job. Azure CLI Run the following command in the same environment and execution account used by your automation: az version Azure CLI 2.37.0 replaced the Azure AD Graph implementation used by az ad with Microsoft Graph. If the reported version is lower than 2.37.0, upgrade to the latest Azure CLI release and test your scripts before the phased shutdown begins. Also check pipeline definitions, package installation steps, and container image tags for an explicitly pinned Azure CLI version; checking only the version on your local workstation does not verify the version used by automation. For installations that support the built-in updater, run: az upgrade Otherwise, update Azure CLI through the same package manager or installation method originally used, then run the version check again. After upgrading, review the documented Microsoft Graph migration changes because some command arguments, behavior, and output properties changed. For example, Microsoft Graph directory object output uses id, while the corresponding Azure AD Graph property was objectId. This can affect scripts that parse command output. If you encounter a problem after upgrading, report it in the Azure CLI GitHub repository and include the output of az version, the affected command, and a minimal reproduction with secrets removed. Azure PowerShell The Entra ID cmdlets discussed in this post are provided by Az.Resources, so check that module's version rather than relying only on the version of PowerShell itself: Get-Module Az.Resources -ListAvailable | Sort-Object Version -Descending | Select-Object -First 1 Name, Version, Path Az.Resources 5.1.0 introduced the Microsoft Graph implementation for the identity-related cmdlets. If the reported version is lower than 5.1.0, update to the latest Az module, restart the PowerShell session, and test your scripts. Check automation accounts, hosted agents, module caches, and container images separately. Also look for scripts that load a specific old version with Import-Module Az.Resources -RequiredVersion or declare a fixed module version in #Requires. If Az was installed from the PowerShell Gallery, update it with: Update-Module -Name Az -Force Restart PowerShell after the update so that the session does not continue using an older module already loaded in memory. To confirm which module version provides a cmdlet in the current session, run: (Get-Command Get-AzADUser).Module | Select-Object Name, Version, Path After upgrading, review the documented Azure PowerShell migration changes because parameter names, input and output types, and object properties changed. If you encounter a problem after upgrading, report it in the Azure PowerShell GitHub repository and include the Az.Resources version, PowerShell version, affected cmdlet, and a minimal reproduction with secrets removed. Check for direct endpoint calls Tool versions do not identify custom code that bypasses az ad or the Az cmdlets. Search your repositories, pipeline definitions, runbooks, and configuration files for graph.windows.net. Pay particular attention to calls made through az rest , curl, Invoke-RestMethod , or custom HTTP and SDK clients. Any direct call to that host must be migrated to Microsoft Graph regardless of the installed Azure CLI or Azure PowerShell version. If you need help upgrading, locating the source of Azure AD Graph traffic, or troubleshooting an issue related to the retirement, you can ask a question in the Azure CLI GitHub repository or the Azure PowerShell GitHub repository , as appropriate. Include the available version information, affected command or cmdlet, execution environment, error message, and a minimal reproduction or relevant logs with all secrets and personal or tenant-sensitive information removed. The Azure CLI and Azure PowerShell teams can then help you investigate and provide guidance. What you should do Make sure you're on a current, supported version of Azure CLI or Azure PowerShell. Run the checks above and update if you're on an old release. Do not rely on the two-month buffer period: legacy access will be progressively disabled after October 6, 2026, so an old release may stop working before the end of that period. If you use the standalone legacy AzureAD or MSOnline PowerShell modules , these are a separate deprecation track from Az and need their own migration to the Microsoft.Graph PowerShell SDK. This is not something updating the Az module alone resolves — see the dedicated migration guidance referenced below. If you have custom code or scripts calling graph.windows.net directly , those calls will fail outright post-retirement regardless of what version of Azure CLI/PowerShell you run, since this isn't a CLI/PowerShell-specific concern — it's any direct caller of the retired endpoint. Migrate those calls to the Microsoft Graph SDK/API directly. If you received a targeted notification referencing a specific tenant ID , that means telemetry showed residual traffic from that tenant specifically — check any automation, scheduled scripts, or older images/containers associated with that tenant for one of the causes above. References Migrate from Azure AD Graph to Microsoft Graph - Microsoft 365 Developer Blog Azure AD Graph to Microsoft Graph migration FAQ - Microsoft Graph | Microsoft Learn Impact of Microsoft Graph migration in Azure CLI Azure AD to Microsoft Graph migration changes in Azure PowerShell Install Azure CLI / Install Azure PowerShell Migrate from the AzureAD and MSOnline PowerShell modules to Microsoft Graph PowerShell

Remote PC connections in Windows App on Windows is now generally available

Tue, 06 Oct 2026 23:00:00 +0000

Today, we’re excited to share that remote PC connections in Windows App on Windows is now generally available! Many people depend on remote access to Windows devices for work, testing, learning, and everyday tasks. With remote PC support in Windows App, users can now access and manage physical and virtual Windows devices alongside Windows 365, Azure Virtual Desktop, and Microsoft Dev Box resources in a single experience. A work or school account is not required to use remote PC connections in Windows App on Windows, making the feature accessible to more users. Users will simply authenticate when connecting to their remote PC. A modern way to connect to remote PCs Remote PC support enables users to add and manage direct connections to Windows PCs in Windows App. Users can specify a PC name or IP address, customize display preferences, and configure local resource redirection. Users can save remote PC connections, pin frequently used devices to Favorites, and reconnect to devices they have added to Windows App. Built for more Windows scenarios This milestone is especially important for users and organizations that need flexibility across both cloud and traditional remote access scenarios. Windows App already provides a unified entry point for Windows 365 Cloud PCs, Azure Virtual Desktop, and Microsoft Dev Box. Adding Remote PC support helps bring another important connection type into that experience. Get started Make sure Remote Desktop is enabled on the PC you want to connect to. Install or update Windows App from the Microsoft Store. Open Windows App and select Add a Remote PC or select the Add button. Add your remote PC using its PC name or IP address. Select Add or Add and Connect. Learn more in the Windows App documentation, Connect to a remote PC . Thank you to everyone who tried remote PC connections during public preview and shared feedback. Your input helped shape this feature and bring it to general availability. Please continue sharing your feedback as we keep improving the experience. Continue the conversation. Find best practices. Bookmark the Windows Tech Community , then follow us on LinkedIn or @MSWindowsITPro for updates. Looking for support? Visit Windows on Microsoft Q&A .

Try SqlClient’s new connection pool for faster parallel connections

Tue, 06 Oct 2026 22:42:12 +0000

You told us that applications using Microsoft.Data.SqlClient can take too long to establish the database connections they need. When many requests need connections at the same time, waiting for the connection pool to grow can delay application readiness and increase latency. This can happen even in common situations like querying several pieces of metadata during […] The post Try SqlClient’s new connection pool for faster parallel connections appeared first on Azure SQL Dev Corner .

Retirement: Pod name dimension in AKS pod platform metrics

Tue, 06 Oct 2026 22:37:54 +0000

Beginning September 30, 2027, support for the pod name dimension on the following Azure Monitor platform metrics is retiring, and these metrics are transitioning to aggregate pod counters:Number of pods by phase (kube_pod_status_phase)Number of pods in Re

Introducing Grok 4.7 on Microsoft Foundry

Tue, 06 Oct 2026 21:11:11 +0000

Today, Grok 4.7 from SpaceXAI is generally available in Microsoft Foundry Models, expanding the portfolio of leading models available to developers and enterprises building the next generation of AI applications. Based on SpaceXAI's latest model release, Grok 4.7 is designed for advanced reasoning, long-horizon problem solving, software engineering, and agentic workflows, making it particularly well suited for complex technical and knowledge-intensive tasks. As organizations move beyond chat experiences toward autonomous agents and AI-powered workflows, demand continues to grow for models that can reason through multi-step problems, effectively use tools, and maintain context across longer tasks. Grok 4.7 was developed with these scenarios in mind, incorporating enhanced training focused on reasoning, software engineering, technical domains, productivity workflows, and agentic reinforcement learning environments. Built for advanced engineering workflows Grok 4.7 was designed to tackle complex technical tasks that require extended reasoning, planning, and execution. In addition to strong coding capabilities, the model was trained and evaluated across software engineering, hardware design, Computer-Aided Design (CAD) generation, and other engineering-focused domains Benchmark highlights 71.0% on DeepSWEv1.1 Benchmarks are from model provider (SpaceXAI). DeepSWEv1.1 evaluates coding agents on 113 original, long-horizon software engineering tasks across 91 active repositories and five languages. Beyond software, Grok 4.7 demonstrated strong results on CADGenBench, which measures a model's ability to generate executable CAD geometry from design requirements. This reflects SpaceXAI's broader focus on applying AI to engineering and technical problem solving in domains that extend beyond code generation. Supporting advanced knowledge work Grok 4.7 also demonstrates strong performance across knowledge-work scenarios that require planning, analysis, and synthesis of information. The model card highlights evaluations covering professional workflows that involve handling documents, structured information, and multi-step reasoning tasks. These strengths make the model a compelling option for organizations building research assistants, enterprise copilots, analyst tools, and workflow automation solutions. As businesses increasingly look to automate repetitive tasks while helping employees focus on higher-value work, models that combine reasoning, planning, and execution become increasingly valuable. Benchmark highlights 19.6% on Harvey’s final score Benchmarks are from model provider (SpaceXAI) The Legal Agent Benchmark evaluates long-horizon legal work organized around realistic client matters. Agents use six file and terminal tools plus document, presentation, and spreadsheet skills to produce work against task-specific criteria. Pricing Deployment Context Window Input/1M Tokens Output/1M Tokens Cache/1M Tokens Global Standard Short context <200K tokens $2.00 $6.00 $0.50 Long context >=200K tokens $4.00 $12.00 $1.00 US DataZone Short context <200K tokens $2.20 $6.60 $0.55 Long context >=200K tokens $4.40 $13.20 $1.10 Built for developers Grok 4.7 is available in Microsoft Foundry through Global Standard and US Data Zone Standard deployments, giving developers flexibility in how they deploy the model for their applications. Developers can integrate Grok models using familiar Chat Completions and Responses APIs , with support for capabilities such as tool calling and streaming . Foundry also supports authentication using Microsoft Entra ID or API keys, making it easier to integrate Grok into existing applications and agentic workflows. Grok 4.7 is also planned to support up to 500K context from launch , enabling developers to work across larger codebases, documents, and long-running workflows Enterprise-ready through Foundry By bringing Grok 4.7 into Foundry, developers gain access to the model through a unified platform designed for enterprise AI development. With Foundry, teams can discover, evaluate, deploy, and govern AI models using a consistent development experience. Customers can compare Grok 4.7 with other leading foundation models, integrate it into existing applications and agents, and take advantage of Foundry's tools for observability, evaluation, and responsible AI practices. This flexibility is particularly important as organizations adopt multi-model strategies, selecting different models for different use cases rather than relying on a single model across all workloads. Foundry makes it easier to experiment, iterate, and operationalize AI solutions while maintaining enterprise-grade governance and control. Get started Grok 4.7 is now generally available in Microsoft Foundry Models . Developers can deploy the model, evaluate it against their own scenarios, and integrate it into applications and agents using Foundry APIs. → Follow the guide: Deploy and use Grok models in Foundry f or integrating Grok into your applications. → Compare models: Use Foundry's evaluation tools to benchmark Grok 4.7 against other models on your specific use cases.

Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Global Industrial AIoT Platforms

Tue, 06 Oct 2026 21:00:00 +0000

We’re proud to share that Microsoft has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Global Industrial AIoT Platforms. The post Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Global Industrial AIoT Platforms appeared first on Microsoft Azure Blog .

Unleash Innovation at the Frontier: Join the Agent-a-thon

Tue, 06 Oct 2026 20:57:29 +0000

What if you could move beyond simply using AI and start building solutions that transform how work gets done? The Frontier Innovation Series: Agent-a-thon is a hands-on experience designed for innovators, makers, technologists, and business leaders who are ready to explore the next frontier of AI: intelligent agents. As organizations embrace AI at scale, the focus is shifting from individual productivity tools to agent-powered solutions that can automate processes, accelerate decision-making, and unlock entirely new ways of working. Microsoft describes this evolution as part of the journey to becoming a Frontier Firm, where AI becomes an integrated and repeatable capability across the organization. Why Attend? The Agent-a-thon is more than a traditional workshop. It is an opportunity to roll up your sleeves, collaborate with peers, and gain practical experience designing and building AI-powered agents that address real business challenges. Participants will have the opportunity to: Explore the latest advancements in agentic AI Learn how intelligent agents can streamline workflows and automate repetitive tasks Collaborate with experts and fellow innovators Discover practical use cases that can drive measurable business impact Gain experience turning ideas into working AI solutions Whether you're in IT, operations, business leadership, development, or innovation roles, you'll leave with actionable knowledge and new ideas that can be applied immediately within your organization. From Productivity to Transformation Many organizations have already seen the benefits of AI-assisted productivity. The next step is leveraging agents that can reason, orchestrate actions, and work alongside employees to achieve business outcomes. This transition represents one of the most exciting opportunities in today's AI landscape. Organizations that develop these capabilities early will be better positioned to innovate, adapt, and compete in an increasingly AI-driven world. Learn by Building The best way to understand the power of agents is to create them. The Agent-a-thon provides a collaborative environment where participants can experiment, learn new techniques, and gain firsthand experience with the technologies shaping the future of work. You'll walk away with practical skills, fresh inspiration, and a clearer vision of how agentic AI can create value for your teams and customers. Be Part of the Future The organizations leading the next wave of AI transformation will be those that empower their employees to innovate, experiment, and build. Join us at the Frontier Innovation Series: Agent-a-thon and discover how agents can help accelerate innovation, increase efficiency, and create new possibilities for your organization. Register today and start building the future. Register for the Agent-a-thon

Secure Your AI Future: Join the Frontier Innovation Series

Tue, 06 Oct 2026 20:57:16 +0000

AI is transforming every industry at an unprecedented pace. Organizations are moving beyond experimentation and asking a critical question: How do we innovate quickly while maintaining security, governance, and trust? The Frontier Innovation Series: Secure Your AI Innovation and Frontier Journey is designed to help leaders, decision-makers, IT professionals, and innovators answer that question with confidence. As AI becomes embedded in daily operations, successful organizations are discovering that innovation and security are not competing priorities. They are the foundation of sustainable transformation. Microsoft's vision for Frontier Transformation emphasizes accelerating AI adoption while ensuring organizations can protect their data, safeguard intellectual property, and maintain compliance as they scale AI solutions. Why Attend? This event brings together industry experts, technology leaders, and AI practitioners to explore how organizations can: Build a secure foundation for AI innovation Navigate the evolving AI landscape with confidence Understand governance, compliance, and risk management strategies Accelerate business value while maintaining trust Prepare their workforce and technology environments for the next wave of AI-powered transformation Attendees will gain practical insights into how leading organizations are moving from AI pilots to enterprise-scale adoption while balancing innovation with responsible AI practices. The Frontier Opportunity Organizations that succeed with AI are not simply deploying new technology. They are reimagining how work gets done, empowering employees with intelligent tools, and creating new opportunities for growth and impact. Microsoft's Frontier Transformation approach focuses on embedding AI into the flow of work while maintaining strong security, compliance, and operational controls. Whether you are just beginning your AI journey or looking to scale existing initiatives, this event will provide valuable perspectives on building an AI strategy that is both ambitious and secure. Connect, Learn, and Innovate Beyond the sessions, the Frontier Innovation Series offers a unique opportunity to engage with peers facing similar challenges, learn from real-world experiences, and discover practical approaches for accelerating AI adoption responsibly. The future belongs to organizations that can innovate boldly while earning and maintaining trust. Join us to learn how to secure your AI innovation journey and unlock the full potential of AI for your organization. Register today and take the next step in your Frontier journey. Register for the Event

Join Us for the Microsoft Agent Bootcamp: Turn AI Potential into Real-World Impact in Miami!

Tue, 06 Oct 2026 20:57:05 +0000

Event Details When : Thursday, December 10, 2026 at 9:00 AM - 4:00 PM (EST) Where : Microsoft Office, 830 Brickell Plaza, STE 4600, Miami, Florida 33131 Delivery Language : English The era of AI is here, and organizations are quickly moving beyond experimentation to implementation. The question is no longer whether to use AI, but how to build, deploy, and scale solutions that deliver meaningful business outcomes. That's why we're excited to invite you to the Microsoft Agent Bootcamp , a hands-on experience designed to help business and technical leaders learn how to create intelligent agents that solve real-world challenges, streamline operations, and unlock new opportunities across their organizations. Why Attend? AI agents represent the next evolution of productivity and automation. Built on the Microsoft platform, agents can help teams accelerate decision-making, automate repetitive work, improve customer experiences, and enable employees to focus on higher-value activities. During this immersive event, you'll move beyond theory and gain practical experience building and customizing agents that can support your organization's unique mission and objectives. Whether you're a business decision maker, IT professional, developer, architect, or AI enthusiast, this workshop is designed to give you the knowledge and confidence to start your agent journey. What You'll Experience Participants will: Explore the latest Microsoft AI and agent capabilities Learn how agents can transform business processes and employee productivity Gain hands-on experience designing and building intelligent agents Discover best practices for governance, security, and responsible AI Connect with Microsoft experts and peers who are leading AI transformation efforts Leave with actionable ideas and working solutions that can be applied immediately This is not a lecture-based event. The Agent Bootcamp is built around interactive learning, guided exercises, and real-world scenarios that help you translate concepts into practical outcomes. Who Should Attend? This event is ideal for: Business and technology leaders Solution architects and IT professionals Developers and application owners Innovation teams and transformation leaders Anyone interested in leveraging Microsoft AI to drive measurable impact No matter where you are in your AI journey, you'll gain valuable insights, practical skills, and a clearer path forward. Be Part of the Next Wave of Innovation Organizations across every industry are exploring how agentic AI can help them work smarter, move faster, and create greater value. The Microsoft Agent Bootcamp provides a unique opportunity to learn directly from Microsoft experts, collaborate with peers, and gain hands-on experience with the technologies shaping the future of work. Seats are limited, so we encourage you to reserve your spot today. Register here: Microsoft Agent Bootcamp Registration We look forward to seeing you there and helping you take the next step from AI curiosity to AI transformation.

Ready to Build the Future? Join Microsoft's Agent Bootcamp in Boulder, Colorado!

Tue, 06 Oct 2026 20:56:53 +0000

Event Details When : Wednesday, October 28, 2026 at 9:00 AM - 4:00 PM (MST) Where : Microsoft Office, 1650 Canyon BLVD, STE 300, Boulder, Colorado 80302 Delivery Language : English The era of AI assistants is here. The era of AI agents is next. If your organization is exploring how to move beyond simple prompts and unlock real business value with Microsoft Copilot, this hands-on Agent Bootcamp is designed for you. Join Microsoft experts, technologists, and industry peers for an immersive experience focused on building, deploying, and scaling AI agents that can automate work, accelerate decision-making, and transform the way teams operate. Register today: Agent Bootcamp Registration Why Attend? Organizations across government and industry are asking the same question: How do we move from AI experimentation to measurable impact? The answer lies in agents. Agents represent the next evolution of AI, acting as intelligent teammates that can reason, perform tasks, retrieve information, and orchestrate business processes on behalf of users. During this bootcamp, you'll learn how to harness the full power of Microsoft's AI platform to create solutions that drive productivity, efficiency, and innovation. This is not a lecture. It is a hands-on experience designed to help you build skills that you can immediately apply within your organization. What You'll Learn During the event, participants will: Explore the latest capabilities across Microsoft Copilot and the Microsoft AI ecosystem Discover real-world use cases for agentic AI Learn how agents can automate repetitive work and streamline business processes Build and customize agents in guided hands-on sessions Understand governance, security, and responsible AI considerations Connect with Microsoft experts and peers tackling similar challenges Whether you're a business leader, IT professional, architect, developer, or innovation champion, you'll leave with practical knowledge and actionable next steps. Who Should Attend? This event is ideal for: Business and technology decision makers Copilot champions and adoption leaders Solution architects and developers Data and AI professionals Innovation and transformation teams Anyone interested in the future of AI-powered work No matter where you are in your AI journey, you'll gain valuable insights and hands-on experience that will help you accelerate adoption and deliver meaningful outcomes. The Opportunity is Now Organizations that successfully embrace agentic AI will be positioned to operate faster, make better decisions, and empower employees with a new generation of digital teammates. The question is no longer whether agents will change the way we work. The question is how quickly you can learn to put them to work for your organization. Seats are limited, so reserve your spot today and join us for an engaging, interactive experience that will help you turn AI potential into real-world impact. Register Now Secure Your Seat We look forward to seeing you there!

Upcoming SQL and AI Events to Put on Your Calendar

Tue, 06 Oct 2026 20:50:48 +0000

Developers, database administrators, data professionals, architects and technology decision makers have several opportunities to connect, learn and gain hands-on experience this fall. 2027 Q4 SQL Events Date Event City & region Registration Fri, Oct 16, 2026 💻 SQL AI App in a Day workshop Sanford, Florida Workshop Sat, Oct 17, 2026 🤝 Orlando’s 19th Annual […] The post Upcoming SQL and AI Events to Put on Your Calendar appeared first on Azure SQL Dev Corner .

Responsible AI in Azure: The 6 Principles Every AI Solution Needs

Tue, 06 Oct 2026 20:12:02 +0000

If an AI chatbot makes a promise your company can’t keep, who’s responsible? In 2024, a Canadian tribunal answered that question when Air Canada argued its chatbot was responsible for its own words. The tribunal disagreed, and that case gets to the heart of one of Microsoft’s six principles of responsible AI. The latest video … Responsible AI in Azure: The 6 Principles Every AI Solution Needs Read More » The post Responsible AI in Azure: The 6 Principles Every AI Solution Needs appeared first on Ciraltos .

Retirement: Azure App Service on Azure Stack Hub

Tue, 06 Oct 2026 18:24:43 +0000

Azure App Service on Azure Stack Hub will be retired on September 30, 2029. Starting September 30, 2026, new installations will no longer be supported, and no new product releases, features, or enhancements will be made available. Existing supported deplo

Retirement: Support for Java 8, 11 and 17 will end on September 1, 2027

Tue, 06 Oct 2026 18:21:59 +0000

On September 1, 2027 support for Java 8, 11 and 17 will end. Your apps that are hosted on App Service will continue to run, but security updates will no longer be available, and we’ll no longer provide customer service for Java 8, 11 and 17.Required actio

GitOps with Argo CD extension for AKS is Now Generally Available

Tue, 06 Oct 2026 18:00:00 +0000

We are excited to announce the general availability (GA) of GitOps with Argo CD extension for Azure Kubernetes Service (AKS)! Argo CD has become one of the most widely adopted GitOps tooling in the Kubernetes ecosystem, helping organizations deploy and operate applications on Kubernetes. As customers scale Kubernetes across teams and environments, they need more than powerful GitOps capabilities. They need a solution that is secure, reliable, observable, and easy to operate in production. GitOps with Argo CD for AKS combines the flexibility of upstream Argo CD with a Microsoft-managed experience that reduces operational complexity while providing the security, integrations, and lifecycle management that enterprises expect from Azure. What's Included in General Availability Secure Authentication and Access Enable enterprise-grade access controls with single sign-on (SSO) through Microsoft Entra ID and securely authenticate to Azure Container Registry (ACR) and Azure DevOps using workload identity federation. By eliminating the need for long-lived credentials and secrets, teams can strengthen security without increasing operational overhead. Enterprise-Ready Security GitOps with Argo CD for AKS is built on hardened Azure Linux images to help reduce exposure to vulnerabilities and improve security posture. Customers can also opt in to automatic patch updates to stay current with critical fixes while reducing the burden of managing the Argo CD platform. Aligned with Upstream Argo CD The managed offering remains aligned with the upstream Argo CD project, allowing customers to use the tools and workflows they already know while benefiting from Microsoft support and lifecycle management. Supported capabilities include: ApplicationSets High Availability (HA) deployments Hub-and-spoke and multi-cluster topologies Azure-Native Observability With support for Azure Managed Prometheus metrics, platform teams can gain deeper operational insights into Argo CD environments and integrate GitOps observability into their existing monitoring workflows. Simplified Lifecycle Management Deploy Argo CD directly through Azure-native tools including the Azure portal, Azure CLI, Terraform etc. Microsoft manages the extension lifecycle, helping teams spend less time operating their GitOps platform and more time delivering applications. Whether you're adopting GitOps for the first time, or looking for a managed alternative to self-hosting Argo CD, GitOps with Argo CD for AKS provides a secure, observable, and enterprise-ready path to application delivery on Kubernetes. Please note that GitOps with Argo CD extension for Azure Arc enabled Kubernetes clusters continues to be available in public preview. Stay tuned for more updates! Get Started Follow this Tutorial to install and configure GitOps with Argo CD extension on your AKS cluster. We're excited to see what you build with GitOps with Argo CD extension on Azure! FAQ: 1. What is GitOps with Argo CD for AKS? GitOps with Argo CD for Azure Kubernetes Service (AKS) is a cluster extension that helps customers deploy and manage Kubernetes applications using Git for example as the source of truth. It combines upstream Argo CD workflows with Azure-native identity, security, observability, and lifecycle management. 2. How is GitOps with Argo CD for AKS different from self-managed Argo CD? GitOps with Argo CD for AKS reduces the operational effort of running Argo CD yourself. Microsoft can manage the extension lifecycle while customers retain familiar Argo CD capabilities and workflows, including Applications, ApplicationSets, the Argo CD UI, and CLI. 3. How does GitOps with Argo CD for AKS improve security? GitOps with Argo CD integrates with Microsoft Entra ID for single sign-on and supports workload identity federation for secure access to services such as Azure Container Registry (ACR) and Azure DevOps, reducing reliance on long-lived credentials. 4. Does GitOps with Argo CD support multiple Kubernetes clusters? Yes. GitOps with Argo CD supports multi-cluster scenarios, including hub-and-spoke architectures, high availability, and ApplicationSets for deploying applications consistently across multiple clusters and environments. 5. How are Argo CD updates and lifecycle management handled? Customers can opt in to automatic updates to help stay current with critical fixes. 6. Is GitOps with Argo CD available for Azure Arc-enabled Kubernetes? Yes, but GitOps with Argo CD for Azure Arc-enabled Kubernetes remains in public preview. This GA announcement applies specifically to Azure Kubernetes Service (AKS).

The New Copilot, Explained Simply: Home, Code and Autopilot

Tue, 06 Oct 2026 17:53:41 +0000

Reading Time: 12 minutes Microsoft has announced some exciting changes to Copilot, introducing three new capabilities called Home, Code and Autopilot. In this blog post, I will discuss each one including additional topics such as Office, Today, Cost and Governance. These changes will gradually be rolled out so may not be available at the time of writing this post. […] Source

Automating Microsoft Entra ID User Lifecycle Management with PowerShell and Microsoft Graph

Tue, 06 Oct 2026 17:44:15 +0000

Introduction — The Problem Managing user accounts throughout the employee lifecycle is one of the common responsibilities of an Identity or Microsoft 365 administrator. When an employee joins an organization, administrators typically create the required identity, assign licenses, configure access, and provision devices and applications. The more challenging part often comes when an employee leaves. A typical offboarding process may require administrators to: Identify employees whose employment has ended Disable the Microsoft Entra ID account Remove directly assigned licenses Record what actions were performed Notify administrators or the appropriate support team Maintain evidence for auditing and troubleshooting If these tasks are performed manually, there is a risk of inconsistent execution, delayed account disablement, forgotten licenses, and incomplete audit records. To explore this problem from an administrator's perspective, I built a PowerShell-based automation project using Microsoft Graph. The project is: Microsoft Entra ID User Lifecycle Automation with PowerShell The goal is to provide a controlled and auditable workflow for detecting expired users and performing defined offboarding actions. 1. Why User Lifecycle Automation Matters Identity lifecycle management is not simply about creating and deleting accounts. It is about controlling access throughout the user's relationship with the organization. A simplified lifecycle can be represented as: Joiner ↓ User Account Created ↓ Access & Licenses Assigned ↓ Employee Active ↓ Mover / Role Change ↓ Employee Leaves ↓ Offboarding ↓ Access Revocation For the leaver stage, organizations need reliable processes to make sure that accounts do not remain active after an employee's departure. Microsoft Entra ID provides native Lifecycle Workflows capabilities for Joiner-Mover-Leaver scenarios. These workflows use tasks and execution conditions to automate lifecycle activities. This project takes a different approach. Instead of replacing native Microsoft capabilities, it demonstrates how administrators can build a custom PowerShell and Microsoft Graph automation layer when they need scripting flexibility, custom reporting, administrator-controlled execution, or a learning platform for Graph automation. 2. Solution Architecture The project is designed around a simple lifecycle pipeline: Employee Created ↓ Expiry / Leave Date Assigned ↓ Daily Automation Runs ↓ Find Expired Users ↓ Validate User ↓ Disable Entra ID Account ↓ Remove Direct Licenses ↓ Create Audit Log ↓ Send Administrator Notification The workflow is divided into separate PowerShell scripts instead of placing everything into a single large script. This separation provides several advantages: Easier troubleshooting Easier testing Clear permissions per function Reusable individual components Better maintainability Easier future integration with scheduling or orchestration systems The project also includes an orchestrator script that coordinates the individual lifecycle stages. 3. Technology Stack The project uses the following technologies: Microsoft Entra ID Microsoft Entra ID provides the identity platform where users, accounts, licenses, and lifecycle-related attributes are managed. The project uses the user's: employeeLeaveDateTime property as the lifecycle date. Microsoft documents employeeLeaveDateTime as an attribute that can be used with leaver lifecycle workflows. Microsoft Graph Microsoft Graph provides the API layer used by the PowerShell scripts. The project uses Graph operations for: Reading users Updating user attributes Disabling accounts Reading license information Removing directly assigned licenses Sending administrator notifications PowerShell PowerShell provides the automation and orchestration layer. The project is designed for Windows PowerShell 5.1+ and uses Microsoft Graph PowerShell modules. 4. Automation Workflow The complete workflow consists of several stages. Stage 1 — Assign an Expiry Date The administrator can assign an employee leave date to an Entra ID user. The project stores this information using: employeeLeaveDateTime For example: Employee Leave Date ↓ 2026-10-01 The project then uses this value during its daily detection process. Microsoft Graph supports updating employeeLeaveDateTime using Update-MgUser. Stage 2 — Detect Expired Users The detection script retrieves users and checks their configured leave dates. The basic logic is: Leave Date < Today's Date ↓ Expired Users whose leave date is today are not treated as expired by this implementation. The detection stage is intentionally read-only. It does not: Disable users Remove licenses Modify accounts Send notifications Write lifecycle audit events Instead, it generates a report that can be reviewed before taking action. Stage 3 — Disable Expired Users Once an expired and enabled user is identified, the disable stage can be executed. The project re-checks the user before making the change. This is important because the state may have changed between detection and execution. The script verifies that: User still exists ↓ Account is still enabled ↓ Leave date is still expired ↓ Disable account This reduces the chance of acting on stale information. Stage 4 — Remove Directly Assigned Licenses After successful account disablement, the automation can remove directly assigned licenses. The project deliberately distinguishes between: Direct license assignment and Group-based license assignment For direct assignments, Microsoft Graph's Set-MgUserLicense API supports adding and removing licenses. For group-based licensing, removing the user's license directly is generally not the correct lifecycle operation. Instead, the appropriate approach is to manage the user's membership in the licensing group according to the organization's access model. Therefore, this project focuses on directly assigned licenses . Stage 5 — Audit Every important lifecycle action is recorded in an audit CSV. The audit information includes fields such as: Event ID Timestamp Action Display Name User Principal Name Employee Leave Date Previous Account Status New Account Status Result Performed By Windows User Computer Name Tenant ID Notification Status Notification Timestamp This provides an execution history that can be used for: Troubleshooting Operational review Compliance evidence Change tracking Incident investigation The audit process also handles migration from an older audit schema so that historical records can be retained when the schema evolves. Stage 6 — Administrator Notification After successful lifecycle actions are recorded, the notification script can send a summary to the administrator. The notification contains information such as: Event ID Timestamp Action User Leave date Previous account status New account status Result Performed By Computer The project uses Microsoft Graph's Send-MgUserMail functionality for email notification. This means the automation does not require a separate SMTP implementation. 5. Script-by-Script Explanation The repository is structured into individual scripts. 01 — Set User Expiry Date Scripts/01-Set-UserExpiryDate.ps1 Purpose: Set or update the user's employeeLeaveDateTime. This provides the lifecycle date that the detection process evaluates. 02 — Get Expired Users Scripts/02-Get-ExpiredUsers.ps1 Purpose: Detect users whose configured leave date has passed. Characteristics: Read-only Retrieves users from Microsoft Entra ID Checks employeeLeaveDateTime Identifies expired users Generates a CSV report Required permission: User.Read.All 03 — Disable Expired Users Scripts/03-Disable-ExpiredUsers.ps1 Purpose: Disable expired accounts that are still enabled. The script performs validation before changing the account. It also supports controlled execution and preview scenarios. 04 — Remove User Licenses Scripts/04-Remove-UserLicenses.ps1 Purpose: Remove directly assigned licenses from a user. The script: Retrieves the user Retrieves assigned licenses Maps license IDs to license information Displays the licenses Confirms the action when running interactively Removes direct assignments Re-reads the user Verifies the result Generates a report Required permission includes: LicenseAssignment.ReadWrite.All Microsoft documents this permission for direct license assignment operations through Graph. 05 — Write Audit Log Scripts/05-Write-AuditLog.ps1 Purpose: Create a structured record of lifecycle actions. The script is responsible for maintaining the audit trail rather than performing the lifecycle action itself. This separation makes it possible to reuse the audit mechanism for future lifecycle operations. 06 — Send Administrator Notification Scripts/06-Send-AdminNotification.ps1 Purpose: Send an administrator notification containing successful lifecycle actions. The notification process also updates the audit records to indicate that the corresponding events were notified. Run — Lifecycle Orchestrator Scripts/Run-EntraUserLifecycle.ps1 This is the main orchestration script. It coordinates the lifecycle stages: 02 Detection ↓ 03 Disable ↓ 04 License Removal ↓ 05 Audit ↓ 06 Notification The orchestrator is designed to keep the individual scripts modular while providing a single operational entry point. 6. Safety Model One of the most important design goals of the project is preventing accidental destructive operations. Disabling an account and removing licenses are destructive administrative actions. For that reason, the project supports multiple execution modes. WhatIf Mode The administrator can execute the workflow in preview mode. The purpose is to answer: "What would this automation do if I ran it for real?" The WhatIf process should: Detect expired users Display the users that would be affected Show planned actions Avoid modifying Entra ID Avoid removing licenses Avoid creating lifecycle audit events Avoid sending lifecycle notification emails This makes WhatIf useful for initial validation and troubleshooting. Interactive Confirmation Normal execution uses administrator confirmation before destructive actions. The lifecycle process separates the decisions: Disable expired accounts? ↓ Yes / No ↓ Disable accounts ↓ Remove direct licenses? ↓ Yes / No This is intentionally different from automatically performing every action immediately. Force Mode For controlled automation scenarios, the project also supports: -Force Force mode bypasses interactive confirmation. This is useful when the orchestrator is executed through a scheduled task or another controlled automation mechanism. The administrator should only use Force mode after validating the environment and lifecycle rules. 7. License Management License management requires particular attention. A user can have licenses assigned directly or through group-based licensing. For example: User ├── Direct License └── Group-Based License This project handles the direct license scenario. Direct licenses can be removed using Microsoft Graph. Group-based licensing should instead be managed through the appropriate licensing group. This distinction is important because simply removing a license from a user does not necessarily represent the correct access-management action when the license is inherited through group membership. The project therefore avoids presenting license removal as a universal "remove all access" operation. 8. Audit Logging Automation without auditability can create another operational problem. If an automation disables an account at 2:00 AM, administrators should be able to determine: Which user was affected? When did the action occur? What action was performed? Was the operation successful? Who executed the automation? From which computer? Was a notification sent? The project records these details in a structured CSV audit file. Example lifecycle event: Action: Disable Result: Success Previous Status: Enabled New Status: Disabled Performed By: Administrator Computer: Management Server A second event can record license removal: Action: RemoveLicense Result: Success This provides a simple but useful operational audit trail. 9. Administrator Notifications After successful actions are completed, administrators should not need to manually open CSV files every day just to determine whether the automation worked. The notification component provides a summary of successful actions. The email can contain multiple lifecycle events in a single message. For example: Entra ID Lifecycle Automation - 2 Action(s) Action Result ------------------------- Disable Success RemoveLicense Success The message also contains contextual information such as the administrator account and computer from which the automation was executed. The project uses Microsoft Graph mail functionality rather than implementing a separate SMTP service. Microsoft provides Send-MgUserMail for sending messages through Graph. 10. Permissions & Least Privilege Permission design is an important part of Microsoft Graph automation. The project separates permissions according to script responsibilities. A simplified model is: Script Purpose Required Permission 01 Set expiry date User.ReadWrite.All / lifecycle attribute permissions depending on implementation 02 Detect users User.Read.All 03 Disable users User.Read.All + User.ReadWrite.All 04 Remove direct licenses User.Read.All + LicenseAssignment.ReadWrite.All 05 Audit Local file access 06 Send notification User.Read.All + Mail.Send The actual production permission model should be reviewed and reduced according to the authentication method and organizational requirements. Microsoft's documentation recommends using the least-privileged permission available for the required operation. For example, the detection script only needs to read users, so it should not require write permissions simply because another script in the project needs them. This separation is one of the areas I intend to improve further as the project evolves. 11. Testing Before using lifecycle automation against production users, testing is essential. The project was tested using controlled test accounts. The testing process included: Expiry Date Testing A test user's employeeLeaveDateTime was configured. The detection script was then used to verify that the user appeared in the expected report. Detection Testing The detection process was tested against users with: No expiry date Future expiry date Current date Expired date Expired and enabled status Expired and already disabled status WhatIf Testing The full orchestration process was tested in WhatIf mode to verify that expired users were detected without performing destructive operations. Disable Testing A controlled test user was used to verify account disablement. The automation successfully changed the account from: Enabled to: Disabled License Testing A test license was assigned directly to the test account. The automation then detected and removed the direct license. The result was verified by reading the user's assigned licenses again. Audit Testing The resulting Disable and RemoveLicense actions were recorded in the audit log. Notification Testing The notification process successfully generated an administrator email containing the lifecycle actions and their results. The testing approach is documented in the repository's Test Plan. 12. GitHub Repository The complete project, including scripts and documentation, is available on GitHub: Entra ID User Lifecycle Automation — GitHub Repository The repository contains: README.md CHANGELOG.md CONTRIBUTING.md Scripts/ ├── 01-Set-UserExpiryDate.ps1 ├── 02-Get-ExpiredUsers.ps1 ├── 03-Disable-ExpiredUsers.ps1 ├── 04-Remove-UserLicenses.ps1 ├── 05-Write-AuditLog.ps1 ├── 06-Send-AdminNotification.ps1 └── Run-EntraUserLifecycle.ps1 Documentation/ ├── Architecture.md ├── Installation.md ├── Permissions.md ├── Security.md ├── Test-Plan.md └── Troubleshooting.md The repository is intended not only to demonstrate the final automation but also to document how an administrator can understand, test, troubleshoot, and extend it. 13. Future Improvements The current implementation focuses on a controlled and understandable core lifecycle. There are several areas that can be improved in future releases. Certificate-Based Authentication The current implementation can be used interactively with Microsoft Graph. A future production-oriented version can use application authentication with a certificate instead of relying on an interactive administrator session. Least-Privilege Application Permissions The application permission model can be further refined so that each automation scenario receives only the permissions it actually requires. Scheduled Execution The orchestrator can be integrated with: Windows Task Scheduler Azure Automation Azure Functions Other enterprise scheduling platforms Configuration-Driven Execution Future versions can move administrator settings into a controlled configuration file. For example: Admin Email Report Location Notification Settings Execution Mode Lifecycle Rules Improved Group-Based Licensing A future version can provide controlled handling of group-based license assignment by identifying licensing groups and managing group membership according to defined rules. Pester Testing Automated PowerShell unit tests can be added to validate functions and lifecycle logic. GitHub Actions The project can use GitHub Actions to automatically validate PowerShell scripts when changes are submitted. Additional Lifecycle Actions Future lifecycle stages could include: Group membership removal Microsoft Teams access review Application access review Device cleanup Session/token revocation Manager notification Service desk ticket creation These features would need careful security and permission analysis before implementation. 14. Conclusion User lifecycle management is a fundamental part of identity administration. A reliable offboarding process should not depend entirely on an administrator remembering every step. This project demonstrates how Microsoft Entra ID, Microsoft Graph, and PowerShell can be combined to create a controlled lifecycle automation workflow. The key design principles behind the project are: Automate repetitive administrative tasks Separate detection from execution Validate before destructive actions Provide WhatIf capability Require confirmation for manual destructive operations Support controlled Force execution Maintain an audit trail Notify administrators Distinguish direct licensing from group-based licensing Document permissions Test before production deployment Microsoft Entra Lifecycle Workflows already provides native capabilities for Joiner-Mover-Leaver automation, and organizations should evaluate those capabilities first when they meet the requirement. The purpose of this project is not to claim that custom PowerShell should replace native Entra Lifecycle Workflows. Instead, it demonstrates how administrators can understand the underlying identity lifecycle process, work with Microsoft Graph, build controlled automation, and extend the solution for scenarios where custom scripting and operational control are useful. I would welcome feedback from other Microsoft Entra ID, Microsoft 365, Identity, and PowerShell administrators on the architecture, security model, testing approach, and ideas for future improvements. GitHub: Entra ID User Lifecycle Automation #MicrosoftEntraID #MicrosoftGraph #PowerShell #Microsoft365 #Identity #IAM #Automation #Azure #CyberSecurity #IdentityManagement #MicrosoftCommunity

A faster, lighter C# Dev Kit

Tue, 06 Oct 2026 17:05:00 +0000

C# Dev Kit has been rebuilt to open solutions in about a second and run on a fraction of the memory, and this post walks through what changed for you. The post A faster, lighter C# Dev Kit appeared first on .NET Blog .

Bringing Native AOT to the Aspire dashboard

Tue, 06 Oct 2026 17:00:03 +0000

Aspire 13.6 brings Native AOT to the dashboard. Explore the startup and deployment benefits, plus the Blazor, Fluent UI, JSON, and Dapper changes that made it possible. The post Bringing Native AOT to the Aspire dashboard appeared first on Aspire Blog .

Partner Blog | What's new for Microsoft partners: October 2026 edition

Tue, 06 Oct 2026 17:00:00 +0000

Your voice continues to shape how the Microsoft AI Cloud Partner Program evolves. This update brings together the announcements, investments, and resources that matter most to partners right now, so you can prioritize where to focus, what to skill, and which motions to scale as AI becomes central to key workloads. What follows highlights areas of partner opportunity, grounded in feedback from across the ecosystem and aligned to how customers are evolving their cloud and AI strategies. Spotlight Microsoft Ignite 2026 From November 17 to 20, 2026, Microsoft Ignite brings partners, customers, Microsoft leaders, and industry experts together at the Moscone Center in San Francisco and online. The event delivers keynotes, technical sessions, hands-on labs, certifications, and expert insights across Copilot, agentic business applications, cloud and AI platforms, Frontier Transformation, security, and more. Registration is open for both in-person and online attendance, and a schedule builder is now online to help attendees find sessions that align with their business priorities. The new Copilot is here: The opportunity for Microsoft partners The new Microsoft Copilot app opens opportunities across AI advisory, security and governance, agent development, adoption, and managed services for software companies, systems integrators, and channel partners. See more AI Business Solutions partner news. Build. Monetize. Scale. Frontier Accelerate for Marketplace launches to power software companies on Microsoft Marketplace Frontier Accelerate for Marketplace guides software development companies through three stages, Build and Publish, Grow, and Differentiate, connecting Microsoft trusted expertise, savings and investments, and skilled teams to each stage. Eligible partners can move from solution readiness to Marketplace transactions and co-sell momentum. See more Microsoft Marketplace partner news. CSP growth margins are now generally available Growth margins now give eligible Cloud Solution Provider (CSP) distributors and direct bill partners incremental margin on qualifying Microsoft 365 growth opportunities. Partners can validate customer eligibility through the eligibility API and download eligible SKUs in the Pricing workspace in Partner Center. Program and benefits updates Frontier Partner specialization open for enrollment in Partner Center This specialization validates partners who design, build, deploy, govern, and secure AI agents across Microsoft 365 Copilot, Microsoft Foundry, GitHub Copilot, Microsoft Defender, Microsoft Entra, and Microsoft Purview. Partners who earn it gain badging, priority search, and skill-aligned benefits. Agentic support: Why AI-powered operations are becoming a competitive core for CSP partners Explore how CSP partners can use agentic AI, stronger support processes, and Microsoft resources to build more efficient customer support operations. New CSP activation incentive for Microsoft Copilot Cowork The Copilot Cowork CSP Activation Incentive rewards eligible CSP indirect resellers and direct bill partners for driving customer adoption and usage of Copilot Cowork, on top of existing CSP incentives. CSP software pricing update effective October 1, 2026 A 5% cost of capital uplift applies to annual-term CSP software subscriptions billed monthly, such as Microsoft SQL Server and Windows Server, taking effect for existing subscriptions at renewal. Annual billing and month-to-month subscriptions stay the same. Earn the new Clinical Applications specialization Now available to eligible partners, this specialization recognizes proven expertise deploying Dragon Copilot for healthcare customers. It can unlock co-sell and referral eligibility, funding opportunities, Azure bulk credits, deployment support, and go-to-market assets. Back at your desk? Start FY27 with the resources that matter most MCAPS Start for Partners keynotes and sessions, plus Microsoft Partner FY27 GTM Kickoff videos and presentations, are now available on demand. New resources span skilling, benefits, Copilot, marketing, Marketplace, and partner operations to help partners prepare for Microsoft Ignite. Partner Center Technical Corner: August 2026 edition The August edition covers AI-powered sales recommendations for CSP partners, preparation for growth margins, webhooks for subscription status, the new Check Inventory by Resource Type API, and audit-based validation for Security specializations. Plan today, grow tomorrow: Turn partner investments into sustained demand Omdia research maps 28 critical presales touchpoints, and the linked blog recommends three reinforcing FY27 investments: build expertise, run sustained demand generation, and apply both to Copilot and Frontier Transformation. New in Partner Marketing Center Pro, the Microsoft 365 Copilot Business campaign in a box provides ready-to-use assets to promote Copilot Business trials. Continue reading here

Proactively monitor Azure VPN Gateway tunnel disconnections

Tue, 06 Oct 2026 16:47:21 +0000

Site-to-Site (S2S) VPN connections are a critical component of hybrid connectivity between Azure and on-premises environments. A tunnel outage can impact applications, user access, and business operations. Although Azure VPN Gateway automatically attempts to re-establish a tunnel when connectivity is restored, administrators should be notified immediately when a tunnel disconnects so they can quickly investigate and mitigate the issue. In this article, you'll learn how to configure an Azure Monitor alert that automatically notifies administrators whenever an Azure VPN Gateway tunnel enters a disconnected state. Why monitor VPN tunnel status? VPN tunnels can disconnect for a variety of reasons, including: Internet connectivity issues On-premises VPN device failures IPSec/IKE negotiation issues Network maintenance activities Device reboots or software upgrades By implementing proactive monitoring, organizations can: Reduce Mean Time to Detection (MTTD) Improve network availability Receive automated notifications Step 1: Enable VPN Gateway diagnostic logs Before creating an alert rule, ensure that diagnostic logging is enabled for your VPN Gateway. Navigate to Azure Monitor in the Azure portal. Under Settings, select Diagnostic settings. Select the appropriate Subscription, Resource Group, and Resource Type, then choose your VPN Gateway resource. Click Add diagnostic setting. Provide a name for the diagnostic setting and select AllLogs (or at minimum TunnelDiagnosticLog). Choose Send to Log Analytics Workspace (or Event Hub / Storage Account, as required). Click Save to apply the diagnostic setting. Step 2: Create an alert rule After enabling diagnostics, navigate to Azure Portal > Monitor > Alerts, and select Create > Alert Rule. Scope Select Scope and click Select scope. In the resource selection pane, choose your Virtual Network Gateway (VPN Gateway) resource and click Apply. This sets the VPN Gateway as the target resource for the alert rule. Condition On the Condition tab, select Custom log search as the signal name and choose Aggregated logs as the query type. Enter the following KQL query to identify VPN tunnel disconnection events during the last 10 minutes: AzureDiagnostics | where TimeGenerated > ago(10m) | where Category == "TunnelDiagnosticLog" | where status_s == "Disconnected" | project TimeGenerated, Resource, status_s Configure the measurement settings as follows: Measure: Table rows Aggregation type: Count Aggregation granularity: 5 minutes Threshold type: Static Operator: Greater than Threshold value: 0 This configuration triggers an alert whenever one or more tunnel disconnection events are detected. Actions On the Actions tab, select Use action groups and either choose an existing action group or create a new one. Configure the action group to send notifications through email, SMS, webhook, or other supported notification channels when a VPN tunnel disconnection event is detected. You can also customize the email subject to make alert notifications easier to identify and manage. Details On the Details tab, provide a meaningful Alert Rule Name, select the appropriate Severity, and add a brief description of the alert. This information will help operations teams quickly understand the purpose and importance of the alert when it is triggered. Review + create Review all configuration settings to ensure they are correct, then select Create to deploy the alert rule. Azure Monitor will begin evaluating the configured query and automatically notify the specified recipients whenever a VPN tunnel enters a disconnected state. Summary By combining Azure VPN Gateway diagnostic logs with Azure Monitor alert rules, organizations can proactively monitor VPN tunnel health and receive near real-time notifications when a tunnel disconnects. This approach improves operational visibility, reduces troubleshooting time, and helps maintain reliable hybrid connectivity between Azure and on-premises networks.

Retirement: Always Encrypted with Intel SGX Enclaves

Tue, 06 Oct 2026 16:42:33 +0000

Always Encrypted with Intel SGX enclaves in Azure SQL Database will retire on October 31, 2027 as support for SGX-enabled DC-series hardware is phased out. Customers should transition to Virtualization-Based Security (VBS) enclaves, a hardware-independent