Introducing AI Skill Assessment in Azure API Center
As AI skills become central to enterprise automation and intelligent workflows, ensuring their quality, safety, and discoverability at scale is a growing challenge. Today, we're excited to announce skills assessment in Azure API Center — a built-in, automated quality scoring system powered by the LLM-as-a-judge technique. This capability enables organizations to continuously evaluate AI skills against defined quality standards, giving platform administrators governance controls and giving developers the confidence to adopt skills that are ready for production. What is LLM-as-a-Judge? AI skill assessments using the LLM-as-a-judge technique leverage a large language model to evaluate AI outputs against defined quality criteria — scoring responses across dimensions like accuracy, coherence, and helpfulness. The judge model can be prompted with rubrics, reference answers, or pairwise comparisons, enabling scalable feedback at a fraction of the cost of human annotation. By embedding this technique directly into Azure API Center, teams can now benefit from continuous, automated quality evaluation — without manual review overhead. Default Assessment Criteria: Four Dimensions of Quality API Center comes with default skill assessment criteria out of the box, evaluating skills across four key dimensions — each scored on a 1–5 scale with a default threshold of 3: Documentation Clarity — Evaluates how clearly a skill's purpose and behavior are communicated. Help Completeness — Assesses whether the output serves as a comprehensive standalone reference. Discoverability — Measures how easily functionality can be navigated and found. Safe Usage — Evaluates whether sufficient guidance is provided for safe operation. Enterprise platform administrators can further extend these defaults by defining custom assessment criteria tailored to their organization's specific standards, compliance requirements, and governance policies. Figure 1: Platform administrators configure skill assessment criteria and thresholds in the Azure API Center portal Detailed Quality Reports for Developers Once skills assessment is enabled, developers can view a detailed AI Quality Score report for each skill directly within the API Center portal. This report provides an at-a-glance Pass or Fail status along with per-dimension scores and actionable feedback. Alongside the LLM-based scores, the report includes: Structural Checks — Verifying foundational elements like valid frontmatter, skill name, and body content. Schema Validation — Flags missing sections such as examples or error handling Figure 2: Developers see per-dimension quality scores, structural checks, and schema validation results for each skill in the API Center portal. What This Means for Developers As a developer, this means you can quickly understand the quality and reliability of a skill before adopting it — making informed decisions about which skills are ready to use and which may need further refinement. No more guessing whether a skill is production ready. With skills assessment, every skill in your catalog comes with a transparent quality score, clear actionable feedback, and the confidence that comes from automated, consistent evaluation. Get Started Skills assessment is available now in Azure API Center. Platform administrators can enable assessment, configure criteria, and start evaluating skills from the API Center portal today. To learn more, visit the skills assessment in Azure API Center documentation or try it out in the Azure Portal.Introducing native Service Bus message publishing from Azure API Management (Preview)
We’re excited to announce a preview capability in Azure API Management (APIM) — you can now send messages directly to Azure Service Bus from your APIs using a built-in policy. This enhancement, currently in public preview, simplifies how you connect your API layer with event-driven and asynchronous systems, helping you build more scalable, resilient, and loosely coupled architectures across your enterprise. Why this matters? Modern applications increasingly rely on asynchronous communication and event-driven designs. With this new integration: Any API hosted in API Management can publish to Service Bus — no SDKs, custom code, or middleware required. Partners, clients, and IoT devices can send data through standard HTTP calls, even if they don’t support AMQP natively. You stay in full control with authentication, throttling, and logging managed centrally in API Management. Your systems scale more smoothly by decoupling front-end requests from backend processing. How it works The new send-service-bus-message policy allows API Management to forward payloads from API calls directly into Service Bus queues or topics. High-level flow A client sends a standard HTTP request to your API endpoint in API Management. The policy executes and sends the payload as a message to Service Bus. Downstream consumers such as Logic Apps, Azure Functions, or microservices process those messages asynchronously. All configurations happen in API Management — no code changes or new infrastructure are required. Getting started You can try it out in minutes: Set up a Service Bus namespace and create a queue or topic. Enable a managed identity (system-assigned or user-assigned) on your API Management instance. Grant the identity the “Service Bus data sender” role in Azure RBAC, scoped to your queue/ topic. Add the policy to your API operation: <send-service-bus-message queue-name="orders"> <payload>@(context.Request.Body.As<string>())</payload> </send-service-bus-message> Once saved, each API call publishes its payload to the Service Bus queue or topic. 📖 Learn more. Common use cases This capability makes it easy to integrate your APIs into event-driven workflows: Order processing – Queue incoming orders for fulfillment or billing. Event notifications – Trigger internal workflows across multiple applications. Telemetry ingestion – Forward IoT or mobile app data to Service Bus for analytics. Partner integrations – Offer REST-based endpoints for external systems while maintaining policy-based control. Each of these scenarios benefits from simplified integration, centralized governance, and improved reliability. Secure and governed by design The integration uses managed identities for secure communication between API Management and Service Bus — no secrets required. You can further apply enterprise-grade controls: Enforce rate limits, quotas, and authorization through APIM policies. Gain API-level logging and tracing for each message sent. Use Service Bus metrics to monitor downstream processing. Together, these tools help you maintain a consistent security posture across your APIs and messaging layer. Build modern, event-driven architectures With this feature, API Management can serve as a bridge to your event-driven backbone. Start small by queuing a single API’s workload, or extend to enterprise-wide event distribution using topics and subscriptions. You’ll reduce architectural complexity while enabling more flexible, scalable, and decoupled application patterns. Learn more: Get the full walkthrough and examples in the documentation 👉 hereIntroducing the plugin marketplace for Azure API Center
Today, we're excited to announce the public preview of the plugin marketplace endpoint for Azure API Center. This new capability makes it easier than ever for developers to discover and install AI plugins — including MCP servers and skills — directly from the tools they already use, like Claude Code and GitHub Copilot CLI. The problem we're solving As AI plugins and MCP servers become core parts of the developer workflow, teams have struggled with a fundamental challenge: there's no central, governed place to find and manage them. Developers hunt through documentation, Teams messages, and wikis — and platform teams have no reliable way to ensure the right plugins are being used. Azure API Center has built the plugin marketplace to fix this issue What's new When you register plugins in your API Center inventory and enable the API Center portal, we now automatically provision a marketplace.git endpoint at your data plane URL: Your marketplace endpoint is https://<service>.data.<region>.azure-apicenter.ms/workspaces/default/plugins/marketplace.git This endpoint serves as a live, version-controlled catalog of every plugin in your API Center — with metadata, configuration, and install instructions ready for developer tools to consume. Get up and running in seconds We've designed the experience to be as frictionless as possible. Developers can add your organization's marketplace and start installing plugins with just two commands: In Claude Code /plugin marketplace add <url> /plugin install plugin-name@myapicenter In GitHub Copilot CLI /plugin marketplace add <url> /plugin marketplace browse myapicenter Enterprise-ready from day one The plugin marketplace isn't just convenient — it's governed. Access to the marketplace endpoint inherits the same authentication model you configured for your API Center portal, so your security and compliance posture stays intact. Platform teams remain in full control of what gets published; developers get a seamless, trusted source of truth. Documentation To learn more click here
Migrate Data Ingestion from Data Collector to Log Ingestion
HTTP Data Collector API in Log Analytics workspaces is being deprecated, and will be totally out of support in September 2026. Data Collector actions in logic app using already created API connections (which uses workspace Id & Key) would still work against old custom log tables, however, newly created table will not be able to ingest data, although the connector would still succeed in logic app, but no data will be populated in newly created custom logs. In case new API connection is created for Data Collector action (using workspace Id & Key); these will fail with 403 - Forbidden action. Users should start using the Log Ingestion API to send data to custom tables, and this document will guide users on how to use Log Ingestion API in logic apps. Note: Azure portal currently is update so it doesn't show the Workspace keys in Log Analytics workspace page, however, Az CLI will still get the keys, but as stated, actions will fail with 403 when using them in Data Collector Action. Creating DCE & DCRs: To utilize the Log Ingestion API, Data Collection Endpoint & Data Collection Rule should be created first. DCE Creation is simple, from azure portal search for DCE, and then create a new one: For DCR creation, it can be either created from the DCR page in Azure Portal, or upon creating the custom log in Log Analytics workspace. DCR Popup You need to upload sample data file, so the custom log table has a schema, it needs to be JSON array. In case the sample log doesn't have a TimeGenerated field, you can easily add it using the mapping function as below: Add the below code in the Transformation box, then click run. Once you complete the DCR creation, we need to get the DCE full endpoint. Getting DCE Log Ingestion Full URL To get the full endpoint URL, please follow the below: 1. Get the DCE Log Ingestion URL from the DCE overview page: 2. On the DCR Page, get the immutable id for the DCR., then click on the JSON view of the DCR resource: 3. From the JSON view, get the stream name from the streamDeclarations field Now the full Log Ingestion URL is: DCE_URL/dataCollectionRules/{immutable_id}/streams/{streamName}?api-version=2023-01-01 It would be similar to: https://mshbou****.westeurope-1.ingest.monitor.azure.com/dataCollectionRules/dcr-7*****4e988bef2995cd52ae/streams/Custom-mshboulLogAPI_CL?api-version=2023-01-01 Granting Logic App MI needed IAM Roles: To call the ingestion endpoint using Logic Apps MI, we need to grant logic apps MI the role "Monitoring Metrics Publisher" over the DCR resource. To do this, open the DCR, from the blade choose Access Control (IAM), and then grant the logic app MI the role "Monitoring Metrics Publisher" Calling Log Ingestion Endpoint from logic apps: To call the ingestion endpoint from logic apps, we need to use the HTTP action, as below, the URI is the full DCE Endpoint we created before. Add the content-type headers, and the json body that contains the log data you want to send. For the authentication, it will be as below: Once executed, it should succeed, with status code 204. For more details on the Log Ingestion API, and the migration, please see our documentation: Migrate from the HTTP Data Collector API to the Log Ingestion API - Azure Monitor | Microsoft Learn Logs Ingestion API in Azure Monitor - Azure Monitor | Microsoft Learn Thanks.Introducing Skills in Azure API Center
The problem Modern applications depend on more than APIs. A single AI workflow might call an LLM, invoke an MCP tool, integrate a third-party service, and reference a business capability spanning dozens of endpoints. Without a central inventory, these assets become impossible to discover, easy to duplicate, and painful to govern. Azure API Center — part of the Azure API Management platform — already catalogs models, agents, and MCP servers alongside traditional APIs. Skills extend that foundation to cover reusable AI capabilities. What is a Skill? As AI agents become more capable, organizations need a way to define and govern what those agents can actually do. Skills are the answer. A Skill in Azure API Center is a reusable, registered capability that AI agents can discover and consume to extend their functionality. Each skill is backed by source code — typically hosted in a Git repository — and describes what it does, what APIs or MCP servers it can access, and who owns it. Think of skills as the building blocks of AI agent behavior, promoted into a governed inventory alongside your APIs, MCP servers, models, and agents. Example: A "Code Review Skill" performs automated code reviews using static analysis. It is registered in API Center with a Source URL pointing to its GitHub repo, allowed to access your code analysis API, and discoverable by any AI agent in your organization. How Skills work in API Center Skills can be added to your inventory in two ways: registered manually through the Azure portal, or synchronized automatically from a connected Git repository. Both approaches end up in the same governed catalog, discoverable through the API Center portal. Option 1: Register a Skill manually Use the Azure portal to register a skill directly. Navigate to Inventory > Assets in your API center, select + Register an asset > Skill, and fill in the registration form. Figure 2: Register a skill form in the Azure portal. The form captures everything needed to make a skill discoverable and governable: Field Description Title Display name for the skill (e.g. Code Review Skill). Identification Auto-generated URL slug based on the title. Editable. Summary One-line description of what the skill does. Description Full detail on capabilities, use cases, and expected behavior. Lifecycle stage Current state: Design, Preview, Production, or Deprecated. Source URL Git repository URL for the skill source code. Allowed tools The APIs or MCP servers from your inventory this skill is permitted to access. Enforces governance at the capability level. License Licensing terms: MIT, Apache 2.0, Proprietary, etc. Contact information Owner or support contact for the skill. Governance note: The Allowed tools field is key for AI governance. It explicitly defines which APIs and MCP servers a skill can invoke — preventing uncontrolled access and making security review straightforward. Option 2: Sync Skills from a Git repository For teams managing skills in source control, API Center can integrate directly with a Git repository and synchronize skill information automatically. This is the recommended approach for teams practicing GitOps or managing many skills at scale. Figure 3: Integrating a Git repository to sync skills automatically into API Center. When you configure a Git integration, API Center: Creates an Environment representing the repository as a source of skills Scans for files matching the configured pattern (default: **/skill.md) Syncs matching skills into your inventory and keeps them current as the repo changes For private repositories, a Personal Access Token (PAT) stored in Azure Key Vault is used for authentication. API Center's managed identity retrieves the PAT securely — no credentials are stored in the service itself. Tip: Use the Automatically configure managed identity and assign permissions option when setting up the integration if you haven't pre-configured a managed identity. API Center handles the Key Vault permissions automatically. Discovering Skills in your catalog Once registered — manually or via Git — skills appear in the Inventory > Assets page alongside all other asset types. Linked skills (synced from Git) are visually identified with a link icon, so teams can see at a glance which skills are source-controlled. From the API Center portal, developers and other stakeholders can browse the full skill catalog, filter by lifecycle stage or type, and view detailed information about each skill — including its source URL, allowed tools, and contact information. Figure 4: Skills catalog in API Center portal, showing registered skills and the details related to the skill. Developer experience: The API Center portal gives teams a self-service way to discover approved skills without needing to ask around or search GitHub. The catalog becomes the authoritative source of what's available and what's allowed. Why this matters for AI development teams Skills close a critical gap in AI governance. As organizations deploy AI agents, they need to know — and control — what those agents can do. Without a governed skill registry, capability discovery is ad hoc, reuse is low, and security review is difficult. By bringing skills into Azure API Center alongside APIs, MCP servers, models, and agents, teams get: A single inventory for all the assets AI agents depend on Explicit governance over which resources each skill can access via Allowed tools Automated, source-controlled skill registration via Git integration Discoverability for developers and AI systems through the API Center portal Consistent lifecycle management — Design through Production to Deprecated API Center, as part of the Azure API Management platform and the broader AI Gateway vision, is evolving into the system of record for AI-ready development. Skills are the latest step in that direction. Available now Skills are available today in Azure API Center (preview). To register your first skill: Sign in to the Azure portal and navigate to your API Center instance In the sidebar, select Inventory > Assets Select + Register an asset > Skill Fill in the registration form and select Create → Register and discover skills in Azure API Center (docs) → Set up your API Center portal → Explore the Azure API Management platformUpdate To API Management Workspaces Breaking Changes: Built-in Gateway & Tiers Support
What’s changing? If your API Management service uses preview workspaces on the built-in gateway and meets the tier-based limits below, those workspaces will continue to function as-is and will automatically transition to general availability once built-in gateway support is fully announced. API Management tier Limit of workspaces on built-in gateway Premium and Premium v2 Up to 30 workspaces Standard and Standard v2 Up to 5 workspaces Basic and Basic v2 Up to 1 workspace Developer Up to 1 workspace Why this change? We introduced the requirement for workspace gateways to improve reliability and scalability in large, federated API environments. While we continue to recommend workspace gateways, especially for scenarios that require greater scalability, isolation, and long-term flexibility, we understand that many customers have established workflows using the preview workspaces model or need workspaces support in non-Premium tiers. What’s not changing? Other aspects of the workspace-related breaking changes remain in effect. For example, service-level managed identities are not available within workspaces. In addition to workspaces support on the built-in gateway described in the section above, Premium and Premium v2 services will continue to support deploying workspaces with workspace gateways. Resources Workspaces in Azure API Management Original breaking changes announcements Reduced tier availability Requirement for workspace gatewaysNew Azure API management service limits
Azure API Management operates on finite physical infrastructure. To ensure reliable performance for all customers, the service enforces limits calibrated based on: Azure platform capacity and performance characteristics Service tier capabilities Typical customer usage patterns Resource limits are interrelated and tuned to prevent any single aspect from disrupting overall service performance. Changes to service limits - 2026 update Starting March 2026 and over the following several months, Azure API Management is introducing updated resource limits for instances across all tiers. The limits are shown in the following table. Entity/Resource Consumption Developer Basic/ Basic v2 Standard/ Standard v2 Premium/ Premium v2 API operations 3,000 3,000 10,000 50,000 75,000 API tags 1,500 1,500 1,500 2,500 15,000 Named values 5,000 5,000 5,000 10,000 18,000 Loggers 100 100 100 200 400 Products 100 100 200 500 2,000 Subscriptions N/A 10,000 15,000 25,000 75,000 Users N/A 20,000 20,000 50,000 75,000 Workspaces per workspace gateway N/A N/A N/A N/A 30 Self-hosted gateways N/A 5 N/A N/A 100 1 1 Applies to Premium tier only. What's changing Limits in the classic tiers now align with those set in the v2 tiers. Limits are enforced for a smaller set of resource types that are directly related to service capacity and performance, such as API operations, tags, products, and subscriptions. Rollout process New limits roll out in a phased approach by tier as follows: Tier Expected rollout date Consumption Developer Basic Basic v2 March 15, 2026 Standard Standard v2 April 15, 2026 Premium Premium v2 May 15, 2026 Limits policy for existing classic tier customers After the new limits take effect, you can continue using your preexisting API Management resources without interruption. Existing classic tier services, where current usage exceeds the new limits, are "grandfathered" when the new limits are introduced. (Instances in the v2 tiers are already subject to the new limits.) Limits in grandfathered services will be set 10% higher than the customer's observed usage at the time new limits take effect. Grandfathering applies per service and service tier. Other existing services and new services are subject to the new limits when they take effect. Guidelines for limit increases In some cases, you might want to increase a service limit. Before requesting a limit increase, note the following guidelines: Explore strategies to address the issue proactively before requesting a limit increase. See the article here Manage resources within limits. Consider potential impacts of the limit increase on overall service performance and stability. Increasing a limit might affect your service's capacity or increase latency in some service operations. Requesting a limit increase The product team considers requests for limit increases only for customers using services in the following tiers that are designed for medium to large production workloads: Standard and Standard v2 Premium and Premium v2 Requests for limit increases are evaluated on a case-by-case basis and aren't guaranteed. The product team prioritizes Premium and Premium v2 tier customers for limit increases. To request a limit increase, create a support request from the Azure portal. For more information, see Azure support plans. Documentation For more information, please see documentation herePreview: Govern, Secure, and Observe A2A APIs with Azure API Management
Today, we’re announcing the preview support for A2A (Agent2Agent) APIs in Azure API Management. With this capability, organizations can now manage and govern agent APIs alongside AI model APIs, Model Context Protocol (MCP) tools, and traditional APIs such as REST, SOAP, GraphQL, WebSocket, and gRPC — all within a single, consistent API management plane. Extending API Governance into the Agentic Ecosystem As organizations adopt agentic systems, the need for consistent governance, security, and observability grows. With A2A API support, Azure API Management enables you to extend established API practices into the agentic world — ensuring secure access, consistent policy enforcement, and complete visibility for AI agents. A2A APIs in Azure API Management: Mediate JSON-RPC runtime operations with policy support Expose and manage agent cards for users, clients, or other agents Support OpenTelemetry GenAI semantic conventions when logging traces to Application Insights — including "gen_ai.agent.id" and "gen_ai.agent.name" attributes How It Works When you import an A2A API, API Management mediates runtime calls to your agent backend (JSON-RPC only) and exposes the agent card as an operation within the same API. The agent card is transformed automatically to represent the A2A API managed by API Management — with the hostname replaced by API Management’s gateway address, security schemes converted to authentication configured in API Management, and unsupported interfaces removed. When integrated with Application Insights, API Management enriches traces with GenAI-compliant telemetry attributes — allowing easy identification of the agent and deep correlation between API and agent execution traces for monitoring and debugging. Try It Out To import an A2A API: Navigate to the APIs page in the Azure portal and select the A2A Agent tile. Enter your agent card URL. If accessible, the portal will automatically populate relevant settings. Configure the remaining properties, such as API path in API Management. This functionality is currently available only in v2 tiers of API Management and it will continue to roll out to all tiers in the coming months. Start Managing Your Agent APIs With A2A support in Azure API Management, you can now bring agent APIs under the same governance and security umbrella as your existing APIs — strengthening control, security, and observability across your AI and API ecosystems. Learn more about A2A API support in Azure API Management.AI Gateway in Azure API Management Is Now Available in Microsoft Foundry (Preview)
For more than a decade, Azure API Management has been the trusted control plane for API governance, security, and observability on a global scale supporting more than 38,000 customers, almost 3 million APIs, and 3 trillion API requests every month. AI Gateway builds on this foundation, extending API Management’s proven governance, security, and observability model to AI workloads, including models, tools, and agents. Today, more than 1,200 enterprise customers use AI Gateway to safely operationalize AI at scale. As customers accelerate AI adoption, the need for consistent, centralized governance becomes even more critical. AI systems increasingly rely on a mix of models, tools, and agents, each introducing new access patterns and governance requirements. Enterprises need a unified way to ensure all this AI traffic remains secure, compliant, and cost-efficient without slowing down developer productivity. Today, we’re making that significantly easier. AI Gateway is now integrated directly into Microsoft Foundry. This gives Foundry users a simple way to govern, observe, and secure their AI workloads with the same reliability and trust as Azure API Management. This integration brings enterprise-grade AI governance directly into Microsoft Foundry right where teams design, build, and operate their AI applications and agents. It provides a streamlined experience that helps organizations adopt strong governance from day one while keeping full API Management capabilities available for advanced configuration. Governance for models With this integration, customers can create a new AI Gateway instance (powered by API Management Basic v2) or associate an existing API Management resource into their Foundry resource. Once configured, all model deployments in the Foundry resource can be accessed through the AI Gateway hostname, ensuring that calls to models, whether to Azure OpenAI or other models, flow through consistent governance and usage controls. Long-term token quotas and short-term token limits can be managed directly within the Foundry interface, enabling teams to set and adjust usage boundaries without leaving the environment where they build and deploy AI applications and agents. Learn more here. Governance for agents The integration also introduces a unified way to govern agents. Organizations can register agents running anywhere — in Azure, other clouds, or on-premises — into the Foundry Control Plane. These agents appear alongside Foundry-native agents for centralized inventory, monitoring, and governance. Teams can view telemetry collected by AI Gateway directly in Foundry or in Application Insights without any reconfiguration of agents at source. Administrators can block agents posing security, compliance, or cost risks within Foundry or apply advanced governance policies, like throttling or content safety, in Azure API Management. Learn more here. Governance for tools Tools benefit from the same consistent governance model. Foundry users can register Model Context Protocol (MCP) tools hosted across any environment and have them automatically governed through the integrated AI Gateway. These tools appear in the Foundry inventory, making them discoverable to developers and ready for consumption by agents. This reduces the operational overhead of securing and mediating tools, simplifying the path to building agentic applications that safely interact with enterprise systems. Learn more here. Unified governance across Foundry and API Management Together, these capabilities bring the power of AI Gateway directly into Microsoft Foundry removing barriers to adoption while strengthening governance. The experience is streamlined with simple setup, intuitive controls, and immediate value. At the same time, customers retain full access to the breadth and depth of API Management capabilities. When advanced policies, enterprise networking, federated gateways, or fine-grained controls are required, teams can seamlessly shift into the API Management experience without losing continuity. With AI Gateway now part of Microsoft Foundry, teams can build and scale AI applications with confidence knowing that consistent governance, security, and observability are built in from the start. AI Gateway in Microsoft Foundry gives every organization a consistent way to govern AI - models, tools, and agents - with the reliability of API Management and the velocity of Foundry. Getting started To set up and use AI Gateway in Foundry, follow the steps in this article. A new AI Gateway deploys an API Management Basic v2 instance for free for the first 100,000 calls. Explore these new capabilities in depth at Microsoft Ignite. Join the Azure API Management and Microsoft Foundry sessions. If attending the conference in person try the hands-on labs to experience how AI Gateway and Foundry help deliver secure and scalable AI applications and stop by our booths to meet the product teams behind these innovations. Session Speaker(s) Link BRK1706: Innovation Session: Build & Manage AI Apps with Your Agent Factory Yina Arenas, Sarah Bird, Amanda Silver, Marco Casalaina https://ignite.microsoft.com/en-US/sessions/BRK1706?source=sessions BRK113: Upskill AI agents with the Azure app platform Mike Hulme, Balan Subramanian, Shawn Henry https://ignite.microsoft.com/en-US/sessions/BRK113?source=sessions BRK119: Don’t let your AI agents go rogue, secure with Azure API management Anish Tallapureddy, Mike Budzynski https://ignite.microsoft.com/en-US/sessions/BRK119?source=sessions LAB519: Governing AI Apps & Agents with AI Gateway in Azure API Management Annaji sharma Ganti, Galin Iliev https://ignite.microsoft.com/en-US/sessions/LAB519?source=sessions
