Calculating Chargebacks for Business Units/Projects Utilizing a Shared Azure OpenAI Instance
Azure OpenAI Service is at the forefront of technological innovation, offering REST API access to OpenAI's suite of revolutionary language models, including GPT-4, GPT-35-Turbo, and the Embeddings model series. Enhancing Throughput for Scale As enterprises seek to deploy OpenAI's powerful language models across various business units, they often require granular control over configuration and performance metrics. To address this need, Azure OpenAI Service is introducing dedicated throughput, a feature that provides a dedicated connection to OpenAI models with guaranteed performance levels. Throughput is quantified in terms of tokens per second (tokens/sec), allowing organizations to precisely measure and optimize the performance for both prompts and completions. The model of provisioned throughput provides enhanced management and adaptability for varying workloads, guaranteeing system readiness for spikes in demand. This capability also ensures a uniform user experience and steady performance for applications that require real-time responses. Resource Sharing and Chargeback Mechanisms Large organizations frequently provision a singular instance of Azure OpenAI Service that is shared across multiple internal departments. This shared use necessitates an efficient mechanism for allocating costs to each business unit or consumer, based on the number of tokens consumed. This article delves into how chargeback is calculated for each business unit based on their token usage. Leveraging Azure API Management Policies for Token Tracking Azure API Management Policies offer a powerful solution for monitoring and logging the token consumption for each internal application. The process can be summarized in the following steps: ** Sample Code: Refer to this GitHub repository to get a step-by-step instruction on how to build the solution outlined below : private-openai-with-apim-for-chargeback 1. Client Applications Authorizes to API Management To make sure only legitimate clients can call the Azure OpenAI APIs, each client must first authenticate against Azure Active Directory and call APIM endpoint. In this scenario, the API Management service acts on behalf of the backend API, and the calling application requests access to the API Management instance. The scope of the access token is between the calling application and the API Management gateway. In API Management, configure a policy (validate-jwt or validate-azure-ad-token) to validate the token before the gateway passes the request to the backend. 2. APIM redirects the request to OpenAI service via private endpoint. Upon successful verification of the token, Azure API Management (APIM) routes the request to Azure OpenAI service to fetch response for completions endpoint, which also includes prompt and completion token counts. 3. Capture and log API response to Event Hub Leveraging the log-to-eventhub policy to capture outgoing responses for logging or analytics purposes. To use this policy, a logger needs to be configured in the API Management: # API Management service-specific details $apimServiceName = "apim-hello-world" $resourceGroupName = "myResourceGroup" # Create logger $context = New-AzApiManagementContext -ResourceGroupName $resourceGroupName -ServiceName $apimServiceName New-AzApiManagementLogger -Context $context -LoggerId "OpenAiChargeBackLogger" -Name "ApimEventHub" -ConnectionString "Endpoint=sb://<EventHubsNamespace>.servicebus.windows.net/;SharedAccessKeyName=<KeyName>;SharedAccessKey=<key>" -Description "Event hub logger with connection string" Within outbound policies section, pull specific data from the body of the response and send this information to the previously configured EventHub instance. This is not just a simple logging exercise; it is an entry point into a whole ecosystem of real-time analytics and monitoring capabilities: <outbound> <choose> <when condition="@(context.Response.StatusCode == 200)"> <log-to-eventhub logger-id="TokenUsageLogger">@{ var responseBody = context.Response.Body?.As<JObject>(true); return new JObject( new JProperty("Timestamp", DateTime.UtcNow.ToString()), new JProperty("ApiOperation", responseBody["object"].ToString()), new JProperty("AppKey", context.Request.Headers.GetValueOrDefault("Ocp-Apim-Subscription-Key",string.Empty)), new JProperty("PromptTokens", responseBody["usage"]["prompt_tokens"].ToString()), new JProperty("CompletionTokens", responseBody["usage"]["completion_tokens"].ToString()), new JProperty("TotalTokens", responseBody["usage"]["total_tokens"].ToString()) ).ToString(); }</log-to-eventhub> </when> </choose> <base /> </outbound> EventHub serves as a powerful fulcrum, offering seamless integration with a wide array of Azure and Microsoft services. For example, the logged data can be directly streamed to Azure Stream Analytics for real-time analytics or to Power BI for real-time dashboards With Azure Event Grid, the same data can also be used to trigger workflows or automate tasks based on specific conditions met in the incoming responses. Moreover, the architecture is extensible to non-Microsoft services as well. Event Hubs can interact smoothly with external platforms like Apache Spark, allowing you to perform data transformations or feed machine learning models. 4: Data Processing with Azure Functions An Azure Function is invoked when data is sent to the EventHub instance, allowing for bespoke data processing in line with your organization’s unique requirements. For instance, this could range from dispatching the data to Azure Monitor, streaming it to Power BI dashboards, or even sending detailed consumption reports via Azure Communication Service. [Function("TokenUsageFunction")] public async Task Run([EventHubTrigger("%EventHubName%", Connection = "EventHubConnection")] string[] openAiTokenResponse) { //Eventhub Messages arrive as an array foreach (var tokenData in openAiTokenResponse) { try { _logger.LogInformation($"Azure OpenAI Tokens Data Received: {tokenData}"); var OpenAiToken = JsonSerializer.Deserialize<OpenAiToken>(tokenData); if (OpenAiToken == null) { _logger.LogError($"Invalid OpenAi Api Token Response Received. Skipping."); continue; } _telemetryClient.TrackEvent("Azure OpenAI Tokens", OpenAiToken.ToDictionary()); } catch (Exception e) { _logger.LogError($"Error occured when processing TokenData: {tokenData}", e.Message); } } } In the example above, Azure function processes the tokens response data in Event Hub and sends them to Application Insights telemetry, and a basic Dashboard is configured in Azure, displaying the token consumption for each client application. This information can conveniently be used to compute chargeback costs. A sample query used in dashboard above that fetches tokens consumed by a specific client: customEvents | where name contains "Azure OpenAI Tokens" | extend tokenData = parse_json(customDimensions) | where tokenData.AppKey contains "your-client-key" | project Timestamp = tokenData.Timestamp, Stream = tokenData.Stream, ApiOperation = tokenData.ApiOperation, PromptTokens = tokenData.PromptTokens, CompletionTokens = tokenData.CompletionTokens, TotalTokens = tokenData.TotalTokens Azure OpenAI Landing Zone reference architecture A crucial detail to ensure the effectiveness of this approach is to secure the Azure OpenAI service by implementing Private Endpoints and using Managed Identities for App Service to authorize access to Azure AI services. This will limit access so that only the App Service can communicate with the Azure OpenAI service. Failing to do this would render the solution ineffective, as individuals could bypass the APIM/App Service and directly access the OpenAI Service if they get hold of the access key for OpenAI. Refer to Azure OpenAI Landing Zone reference architecture to build a secure and scalable AI environment. Additional Considerations If the client application is external, consider using an Application Gateway in front of the Azure APIM If "streaming" is set to true, tokens count is not returned in response. In that that case libraries like tiktoken (Python), orgpt-3-encoder(javascript) for most GPT-3 models can be used to programmatically calculate tokens count for the user prompt and completion response. A useful guideline to remember is that in typical English text, one token is approximately equal to around 4 characters. This equates to about three-quarters of a word, meaning that 100 tokens are roughly equivalent to 75 words. (P.S. Microsoft does not endorse or guarantee any third-party libraries.) A subscription key or a custom header like app-key can also be used to uniquely identify the client as appId in OAuth token is not very intuitive. Rate-limiting can be implemented for incoming requests using OAuth tokens or Subscription Keys, adding another layer of security and resource management. The solution can also be extended to redirect different clients to different Azure OpenAI instances. For example., some clients utilize an Azure OpenAI instance with default quotas, whereas premium clients get to consume Azure Open AI instance with dedicated throughput. Conclusion Azure OpenAI Service stands as an indispensable tool for organizations seeking to harness the immense power of language models. With the feature of provisioned throughput, clients can define their usage limits in throughput units and freely allocate these to the OpenAI model of their choice. However, the financial commitment can be significant and is dependent on factors like the chosen model's type, size, and utilization. An effective chargeback system offers several advantages, such as heightened accountability, transparent costing, and judicious use of resources within the organization.
What's New in Azure App Service at #MSBuild 2025
New App Service Premium v4 plan The new App Service Premium v4 (Pv4) plan has entered public preview at Microsoft Build 2025 for both Windows and Linux! This new plan is designed to support today's highly demanding application performance, scale, and budgets. Built on the latest "v6" general-purpose virtual machines and memory-optimized x64 Azure hardware with faster processors and NVMe temporary storage, it provides a noticeable performance uplift over prior generations of App Service Premium plans (over 25% in early testing). The Premium v4 offering includes nine new sizes ranging from P0v4 with a single virtual CPU and 4GB RAM all the way up through P5mv4, with 32 virtual CPUs and 256GB RAM, providing CPU and memory options to meet any business need. App Service Premium v4 plans provide attractive price-performance across the entire performance curve for both Windows and Linux customers. Premium v4 customers using pay-as-you-go (PAYG) on Azure App Service for Windows can expect to save up to 24% compared with prior Premium plans. We plan to provide deeper commitment-based discounts such as reserved instances and savings plan at GA. For more detailed pricing on the various CPU and memory options, see the pricing pages for Windows and Linux as well as the Azure Pricing Calculator. App Service currently has Pv4 deployed in a few regions with more regions being regularly added. For more details on how to configure app service plans with Premium v4 as well as a regularly updated list of regional availability, see the product documentation and start taking advantage of faster performance today! 2-zone Availability Zone support is now generally available With a recently completed platform update in May, customers now enjoy the 99.99% Availability Zone (AZ) SLA when running on only two instances (instead of three)! As part of this update more parts of the App Service footprint have enabled AZ support “in place”, which means many existing app service plans can now also use Availability Zones. Availability Zone configuration for app service plans is also now mutable. This means if an app service plan is running on an AZ-enabled part of the App Service footprint, customers can choose to enable and disable Availability Zone support at any time. Read more about the new Availability Zone options in the announcement article! ARM/CLI surface area for Availability Zone support has also been updated to provide increased visibility into AZ configuration details. The same enhanced visibility is also coming to the Azure Portal in June. With these changes customers can determine if an App Service plan is on an AZ-enabled scale unit, as well as how many zones are available for zone spanning. This allows customers to deploy with either two zones, or three zones (where available), of zone spanning for their App Service plans. For App Service plans that are AZ-enabled, customers will also be able to see the physical zone placement of each AZ enabled App Service plan. Availability Zone support is available on the new Premium v4 plan, and also supported with Premium v2, Premium v3, and the dedicated App Service Environment v3 (Isolated V2 plan). Check out the Availability Zone options for your App Service plans and start getting the benefits of zone resiliency today! .NET Aspire on Azure App Service .NET Aspire support is now available in public preview for App Service on Linux! .NET Aspire developers creating applications have an additional deployment option with App Service as a deployment target. Developers can create multi-app/multi-service .NET Aspire applications locally and deploy them into Azure using the new App Service deployment provider. The App Service and .NET Aspire teams worked together to create an App Service “provider” using .NET Aspire’s new “provider model”. The build provider translates the code-centric view of a .NET Aspire application topology into an Azure deployment mapped onto App Service constructs. The App Service provider supports securely deploying multiple .NET Aspire applications, with observability via the familiar .NET Aspire dashboard coming in the near future. The Getting Started with .NET Aspire on Azure App Service blog has instructions on how to create a .NET Aspire project for deployment onto App Service, as well a link for providing feedback. If you happen to be at Build 2025, drop by our booth or the theatre session “DEM548: How .NET Aspire on App Service enhances modern app development” to see live demonstrations of the App Service support for .NET Aspire! Using App Service to build agentic AI apps The last few months of intelligent app development have seen a frenetic pace of change with the rapid evolution of agents on Azure AI Foundry Agent Service and new agent extensibility options like Model Context Protocol (MCP) opening avenues for integrating existing data sources and APIs into agentic architectures. Here's a quick run-down of useful resources published recently: This article demonstrates hosting a remote MCP server on Azure App Service. The sample is an adaptation of the weather service example from the MCP site. The App Service variation also includes an azd template for easy experimentation via a CLI deployment to App Service! This article walks through integrating a .NET Core implementation of a “To-Do” list API running on App Service with an agent created on Azure AI Foundry Agent Service. It’s a straightforward example demonstrating how developers can bring together the power of AI agents with existing web API investments. Quick start guides for using App Service with Azure Open AI in your language of choice -- Python, Node, .NET, and Java. Using Microsoft Research’s latest 1-bit “super-small” language model, BitNet on App Service. Enhance search queries on text data stored in Azure SQL DB using natural language vector functions and Azure App Service. Includes an accompanying azd example. How to use Azure AI Search hybrid search capabilities from App Service with .NET (Blazor), Java (Spring Boot), Node (Express), or Python (FastAPI). Use GitHub Copilot to compare your application’s bicep against a representative “best practices” bicep definition and then generate the necessary bicep diff. In addition, using Sidecar for App Service on Linux, developers can easily connect Phi SLMs to their applications. Examples using the chat completion endpoint in the SLM sidecar extensions are available in this GitHub repo with code examples for .NET, Node, Python and Java. There are also accompanying docs for .NET, Node, Python (FastAPI) and Java (Spring Boot) which go into more details on using the SLM sidecar extensions. The sidecar extensions capability is also now enabled in the Azure Portal. AI Labs at Microsoft Build For those of you attending Microsoft Build in person, we will have labs for additional hands-on experience using AI with Azure App Service. LAB347: Add AI experiences to existing .NET apps using Sidecar in App Service This lab (first lab occurrence and second lab occurrence - see Exercise 4) covers an e-commerce inventory API (written in .NET) integrated with an agent running on Azure AI Foundry Agent Service. When a customer interacts with the AI agent it automatically invokes the appropriate web APIs to fetch real-time inventory information, add/remove products in a shopping cart, and increment/decrement product inventory. This is a great example of an AI powered agent grounded in a company’s ever changing transactional data. As a fun sidenote, GitHub Copilot was used extensively to build >95% of the sample application as well as to generate the OpenAPI specification that integrates the inventory web API with the AI agent! The same AI-on-App Service lab (Exercise 1) walks developers through integrating a basic Azure OpenAI chat interface into a web application. The lab also demonstrates using a background WebJob on Linux with Azure OpenAI (Exercise 2) to categorize user sentiment for product reviews. The lab also shows (Exercise 3) how to use a small language model (SLM) like Microsoft’s Phi-4 model in a WebJob to perform similar categorization, without the need to call out to an LLM. Although SLMs are not as powerful as LLMs, SLMs are an interesting alternative for integrating AI functionality where either cost, or control over AI data flows, are considerations. Azure SRE Agent for App Service One of the big announcements at Build this year was the Agentic DevOps announcement, which includes the new Azure SRE Agent. Designed to empower Site Reliability Engineers (SRE), the SRE Agent is a new agentic service that can manage Azure application platform services. including App Service, Functions, and Azure Container Apps to name just a few. It provides automatic incident response and mitigation, faster root cause analysis (RCA) of production issues, and continuous monitoring of application health and performance. With SRE Agent, you can use a natural language interface for managing your web applications on Azure App Service. To be an early adopter of the Agentic DevOps revolution, check out the announcement blog and sign-up to join the SRE Agent preview as it starts rolling out! WebJobs for App Service on Linux (GA) WebJobs for App Service on Linux just recently GA’d earlier this month. With this functionality developers can implement the same “infra-glue” style of background jobs that they have enjoyed with App service on Windows. Take a look at the documentationdemonstrating WebJobs support for shell scripts, Python, Java, .NET and Node on Linux! As mentioned earlier, the AI-on-App Service lab at this year’s Build conference has two code examples (see Exercise 2 and Exercise 3) demonstrating Linux WebJobs with Azure OpenAI, as well as a locally connected Phi-4 Small Language Model (SLM) sidecar, to categorize user sentiment for submitted product reviews. These are great examples of creatively using WebJobs to perform background batch-style work with your AI resources. Also keep an eye out for the upcoming WebJobs for Windows Containers GA which is planned “soon” this summer! Language and Framework Updates In addition to the release of .NET Aspire support for App Service, the App Service team has kept busy updating myriad Node, Python, Java/JBoss, .NET and PHP versions. To give an idea of the scope of effort keeping language and framework versions up to date across both Windows and Linux, App Service released more than two dozen language/framework specific updates in the last few weeks prior to Build. That represents the ongoing platform commitment to keeping languages regularly updated without the need for developers to explicitly invest time and effort doing so themselves. Just last month, Strapi support was introduced for App Service on Linux! Strapi is an open source headless Javascript based content management system that provides developers a robust platform for developing and delivering content across a variety of formats. The Azure Marketplace Strapi offering provides customization control, global availability and pre-built integration to essential Azure services like Azure Database for MySQL or PostgreSQL and Azure Email Communication Services. Deep dive on the details of hosting Strapi on App Service in this article. The custom error pages feature for App Service has also been updated just prior to Build. Custom error pages enable developers to customize the response rendered for common HTTP errors (403, 502 and 503) which are returned by the platform. This release includes a new option to always render custom errors regardless of whether the HTTP error was platform generated, or application generated. There will also be an Azure Portal update coming in June with support for the new custom error page features! Looking ahead to summer, stay tuned for the impending arrival of .NET 10 preview bits on App Service across both Windows and Linux! Networking and ASE Updates App Service support for public inbound IPv6 traffic is availablein most regions in public preview, with the service working towards a planned GA of inbound IPv6 support during the summer. Inbound IPv6 is supported for both IPv6-only upstream clients, as well dual-stack scenarios where a web application is reachable over either an IPv4 address or an IPv6 address. As part of an upcoming summer release, App Service will be delivering a public preview of *outbound* IPv6 traffic. For details on using IPv6 on App Service, as well to track all of the upcoming updates, consult this article: Announcing inbound IPv6 support in public preview - Azure App Service. For App Service Environment (ASE) customers, App Service will soon be releasing new support for adding custom Certificate Authorities (CAs) to an ASE. This new support will enable securing inbound TLS traffic using certificates issued by a custom Certificate Authority. Hybrid Connections customers will be happy to see that a new version of the App Service Hybrid Connection Manager (HCM) was just released just a few weeks ago. The new HCM delivers updated UX support for both Linux and Windows customers, enhanced logging and connection testing, and a brand new CLI for scripting and command-line management of Hybrid Connections! You might have missed it, but there was a recent addition to the troubleshooting options on App Service with the new Network Troubleshooter! The Network Troubleshooter offers comprehensive analysis and actionable insights to resolve connectivity failures for both Linux and Windows web apps. It tests connectivity to Azure resources like Storage, Redis, SQL Server, MySQL server, and other apps running on App Service. It diagnoses connectivity problems with Private endpoints, Service endpoints, and Internet-based endpoints, detects NAT gateways, and investigates DNS failures with custom DNS servers. Additionally, it provides actionable recommendations and surfaces any network rules it finds that are blocking connectivity. If you regularly wrestle with connectivity challenges, give the Network Troubleshooter a try! Next Steps Developers can learn more about Azure App Service at Getting Started with Azure App Service. Stay up to date on new features and innovations on Azure App Service via Azure Updates as well as the Azure App Service (@AzAppService) X feed. There is always a steady stream of great deep-dive technical articles about App Service as well as the breadth of developer focused Azure services over on the Apps on Azure blog. And lastly take a look at Azure App Service Community Standups hosted on the Microsoft Azure Developers YouTube channel. The Azure App Service Community Standup series regularly features walkthroughs of new and upcoming features from folks that work directly on the product! Build 2025 Session Reference (Note: all times below are listed in Seattle time - Pacific Daylight Time) (Note: some labs have more than one timeslot spanning multiple days) Innovate, deploy, & optimize your apps without infrastructure hassles https://build.microsoft.com/en-US/sessions/BRK201 Monday, May 19 th 11:15 AM – 12:15 PM Pacific Daylight Time Arch, 705 Pike, Level 6, Room 606 Breakout, Streaming Online and Recorded Session (BRK201) Quickly build, deploy, and scale web apps and APIs globally with App Service https://build.microsoft.com/en-US/sessions/BRK200 Tuesday, May 20 th 11:45 AM – 12:45 PM Pacific Daylight Time Arch, 705 Pike, Level 6, Room 608 Breakout, Streaming Online and Recorded Session (BRK200) Simplifying .NET upgrades with GitHub Copilot https://build.microsoft.com/en-US/sessions/DEM549 Monday, May 19 th 5:05 PM - 5:20 PM Pacific Daylight Time Arch, 705 Pike, Level 4, Hub, Theater B Demo Session – Also Recorded (DEM549) Use Azure SRE Agent to automate tasks and increase site reliability https://build.microsoft.com/en-US/sessions/DEM550 Tuesday, May 20 th 5:10 PM - 5:25 PM Pacific Daylight Time Arch, 705 Pike, Level 4, Hub, Theater A Demo Session – Also Recorded (DEM550) How .NET Aspire on App Service enhances modern app development https://build.microsoft.com/en-US/sessions/DEM548 Wednesday, May 21 st 2:00 PM - 2:15 PM Pacific Daylight Time Arch, 705 Pike, Level 4, Hub, Theater B Demo Session – Also Recorded (DEM548) Add AI experiences to existing .NET apps using Sidecars in App Service [Note: Lab participants will be able to try Phi-4 and Azure AI Foundry Agent service scenarios in this lab.] https://build.microsoft.com/en-US/sessions/LAB347 Monday, May 19 th 4:45 PM - 6:00 PM Pacific Daylight Time Arch, 800 Pike, Level 1, Yakima 1 Hands on Lab – In-Person Only (LAB347) You can also work through the lab with your own Azure subscription! Code is available at https://github.com/Azure-Samples/Build2025-LAB347. Deploy the lab resources using the included resource provisioning template (https://github.com/Azure-Samples/Build2025-LAB347/blob/main/resources/lab347.json). You can deploy the template by searching on “Deploy a custom template” in the Azure Portal, and copying and pasting the template into the “Build your own template in the editor option”! Add AI experiences to existing .NET apps using Sidecars in App Service [Note: Lab participants will be able to try Phi-4 and Azure AI Foundry Agent service scenarios in this lab.] https://build.microsoft.com/en-US/sessions/LAB347-R1 Wednesday, May 21 st 4:30 PM - 5:45 PM Pacific Daylight Time Arch, 800 Pike, Lower Level, Skagit 5 Hands on Lab – In-Person Only (LAB347-R1) You can also work through the lab with your own Azure subscription! Code is available at https://github.com/Azure-Samples/Build2025-LAB347. Deploy the lab resources using the included resource provisioning template (https://github.com/Azure-Samples/Build2025-LAB347/blob/main/resources/lab347.json). You can deploy the template by searching on “Deploy a custom template” in the Azure Portal, and copying and pasting the template into the “Build your own template in the editor option”! Modernizing .NET Applications using Azure Migrate and GitHub Copilot https://build.microsoft.com/en-US/sessions/LAB343 Tuesday, May 20 th 5:15 PM - 6:30 PM Pacific Daylight Time Arch, 800 Pike, Level 1, Yakima 1 Hands on Lab – In-Person Only (LAB343) Modernizing .NET Applications using Azure Migrate and GitHub Copilot https://build.microsoft.com/en-US/sessions/LAB343-R1 Thursday, May 22 nd 10:15 AM – 11:30 AM Pacific Daylight Time Arch, 800 Pike, Level 2, Chelan 2 Hands on Lab – In-Person Only (LAB343-R1)Building the Agentic Future
As a business built by developers, for developers, Microsoft has spent decades making it faster, easier and more exciting to create great software. And developers everywhere have turned everything from BASIC and the .NET Framework, to Azure, VS Code, GitHub and more into the digital world we all live in today. But nothing compares to what’s on the horizon as agentic AI redefines both how we build and the apps we’re building. In fact, the promise of agentic AI is so strong that market forecasts predict we’re on track to reach 1.3 billion AI Agents by 2028. Our own data, from 1,500 organizations around the world, shows agent capabilities have jumped as a driver for AI applications from near last to a top three priority when comparing deployments earlier this year to applications being defined today. Of those organizations building AI agents, 41% chose Microsoft to build and run their solutions, significantly more than any other vendor. But within software development the opportunity is even greater, with approximately 50% of businesses intending to incorporate agentic AI into software engineering this year alone. Developers face a fascinating yet challenging world of complex agent workflows, a constant pipeline of new models, new security and governance requirements, and the continued pressure to deliver value from AI, fast, all while contending with decades of legacy applications and technical debt. This week at Microsoft Build, you can see how we’re making this future a reality with new AI-native developer practices and experiences, by extending the value of AI across the entire software lifecycle, and by bringing critical AI, data, and toolchain services directly to the hands of developers, in the most popular developer tools in the world. Agentic DevOps AI has already transformed the way we code, with 15 million developers using GitHub Copilot today to build faster. But coding is only a fraction of the developer’s time. Extending agents across the entire software lifecycle, means developers can move faster from idea to production, boost code quality, and strengthen security, while removing the burden of low value, routine, time consuming tasks. We can even address decades of technical debt and keep apps running smoothly in production. This is the foundation of agentic DevOps—the next evolution of DevOps, reimagined for a world where intelligent agents collaborate with developer teams and with each other. Agents introduced today across GitHub Copilot and Azure operate like a member of your development team, automating and optimizing every stage of the software lifecycle, from performing code reviews, and writing tests to fixing defects and building entire specs. Copilot can even collaborate with other agents to complete complex tasks like resolving production issues. Developers stay at the center of innovation, orchestrating agents for the mundane while focusing their energy on the work that matters most. Customers like EY are already seeing the impact: “The coding agent in GitHub Copilot is opening up doors for each developer to have their own team, all working in parallel to amplify their work. Now we're able to assign tasks that would typically detract from deeper, more complex work, freeing up several hours for focus time." - James Zabinski, DevEx Lead at EY You can learn more about agentic DevOps and the new capabilities announced today from Amanda Silver, Corporate Vice President of Product, Microsoft Developer Division, and Mario Rodriguez, Chief Product Office at GitHub. And be sure to read more from GitHub CEO Thomas Dohmke about the latest with GitHub Copilot. At Microsoft Build, see agentic DevOps in action in the following sessions, available both in-person May 19 - 22 in Seattle and on-demand: BRK100: Reimagining Software Development and DevOps with Agentic AI BRK 113: The Agent Awakens: Collaborative Development with GitHub Copilot BRK118: Accelerate Azure Development with GitHub Copilot, VS Code & AI BRK131: Java App Modernization Simplified with AI BRK102: Agent Mode in Action: AI Coding with Vibe and Spec-Driven Flows BRK101: The Future of .NET App Modernization Streamlined with AI New AI Toolchain Integrations Beyond these new agentic capabilities, we’re also releasing new integrations that bring key services directly to the tools developers are already using. From the 150 million GitHub users to the 50 million monthly users of the VS Code family, we’re making it easier for developers everywhere to build AI apps. If GitHub Copilot changed how we write code, Azure AI Foundry is changing what we can build. And the combination of the two is incredibly powerful. Now we’re bringing leading models from Azure AI Foundry directly into your GitHub experience and workflow, with a new native integration. GitHub models lets you experiment with leading models from OpenAI, Meta, Cohere, Microsoft, Mistral and more. Test and compare performance while building models directly into your codebase all within in GitHub. You can easily select the best model performance and price side by side and swap models with a simple, unified API. And keeping with our enterprise commitment, teams can set guardrails so model selection is secure, responsible, and in line with your team’s policies. Meanwhile, new Azure Native Integrations gives developers seamless access to a curated set of 20 software services from DataDog, New Relic, Pinecone, Pure Storage Cloud and more, directly through Azure portal, SDK, and CLI. With Azure Native Integrations, developers get the flexibility to work with their preferred vendors across the AI toolchain with simplified single sign-on and management, while staying in Azure. Today, we are pleased to announce the addition of even more developer services: Arize AI: Arize’s platform provides essential tooling for AI and agent evaluation, experimentation, and observability at scale. With Arize, developers can easily optimize AI applications through tools for tracing, prompt engineering, dataset curation, and automated evaluations. Learn more. LambdaTest HyperExecute: LambdaTest HyperExecute is an AI-native test execution platform designed to accelerate software testing. It enables developers and testers to run tests up to 70% faster than traditional cloud grids by optimizing test orchestration, observability and streamlining TestOps to expedite release cycles. Learn more. Mistral: Mistral and Microsoft announced a partnership today, which includes integrating Mistral La Plateforme as part of Azure Native Integrations. Mistral La Plateforme provides pay-as-you-go API access to Mistral AI's latest large language models for text generation, embeddings, and function calling. Developers can use this AI platform to build AI-powered applications with retrieval-augmented generation (RAG), fine-tune models for domain-specific tasks, and integrate AI agents into enterprise workflows. MongoDB (Public Preview): MongoDB Atlas is a fully managed cloud database that provides scalability, security, and multi-cloud support for modern applications. Developers can use it to store and search vector embeddings, implement retrieval-augmented generation (RAG), and build AI-powered search and recommendation systems. Learn more. Neon: Neon Serverless Postgres is a fully managed, autoscaling PostgreSQL database designed for instant provisioning, cost efficiency, and AI-native workloads. Developers can use it to rapidly spin up databases for AI agents, store vector embeddings with pgvector, and scale AI applications seamlessly. Learn more. Java and .Net App Modernization Shipping to production isn’t the finish line—and maintaining legacy code shouldn’t slow you down. Today we’re announcing comprehensive resources to help you successfully plan and execute app modernization initiatives, along with new agents in GitHub Copilot to help you modernize at scale, in a fraction of the time. In fact, customers like Ford China are seeing breakthrough results, reducing up to 70% of their Java migration efforts by using GitHub Copilot to automate middleware code migration tasks. Microsoft’s App Modernization Guidance applies decades of enterprise apps experience to help you analyze production apps and prioritize modernization efforts, while applying best practices and technical patterns to ensure success. And now GitHub Copilot transforms the modernization process, handling code assessments, dependency updates, and remediation across your production Java and .NET apps (support for mainframe environments is coming soon!). It generates and executes update plans automatically, while giving you full visibility, control, and a clear summary of changes. You can even raise modernization tasks in GitHub Issues from our proven service Azure Migrate to assign to developer teams. Your apps are more secure, maintainable, and cost-efficient, faster than ever. Learn how we’re reimagining app modernization for the era of AI with the new App Modernization Guidance and the modernization agent in GitHub Copilot to help you modernize your complete app estate. Scaling AI Apps and Agents Sophisticated apps and agents need an equally powerful runtime. And today we’re advancing our complete portfolio, from serverless with Azure Functions and Azure Container Apps, to the control and scale of Azure Kubernetes Service. At Build we’re simplifying how you deploy, test, and operate open-source and custom models on Kubernetes through Kubernetes AI Toolchain Operator (KAITO), making it easy to inference AI models with the flexibility, auto-scaling, pay-per-second pricing, and governance of Azure Container Apps serverless GPU, helping you create real-time, event-driven workflows for AI agents by integrating Azure Functions with Azure AI Foundry Agent Service, and much, much more. The platform you choose to scale your apps has never been more important. With new integrations with Azure AI Foundry, advanced automation that reduces developer overhead, and simplified operations, security and governance, Azure’s app platform can help you deliver the sophisticated, secure AI apps your business demands. To see the full slate of innovations across the app platform, check out: Powering the Next Generation of AI Apps and Agents on the Azure Application Platform Tools that keep pace with how you need to build This week we’re also introducing new enhancements to our tooling to help you build as fast as possible and explore what’s next with AI, all directly from your editor. GitHub Copilot for Azure brings Azure-specific tools into agent mode in VS Code, keeping you in the flow as you create, manage, and troubleshoot cloud apps. Meanwhile the Azure Tools for VS Code extension pack brings everything you need to build apps on Azure using GitHub Copilot to VS Code, making it easy to discover and interact with cloud services that power your applications. Microsoft’s gallery of AI App Templates continues to expand, helping you rapidly move from concept to production app, deployed on Azure. Each template includes fully working applications, complete with app code, AI features, infrastructure as code (IaC), configurable CI/CD pipelines with GitHub Actions, along with an application architecture, ready to deploy to Azure. These templates reflect the most common patterns and use cases we see across our AI customers, from getting started with AI agents to building GenAI chat experiences with your enterprise data and helping you learn how to use best practices such as keyless authentication. Learn more by reading the latest on Build Apps and Agents with Visual Studio Code and Azure Building the agentic future The emergence of agentic DevOps, the new wave of development powered by GitHub Copilot and new services launching across Microsoft Build will be transformative. But just as we’ve seen over the first 50 years of Microsoft’s history, the real impact will come from the global community of developers. You all have the power to turn these tools and platforms into advanced AI apps and agents that make every business move faster, operate more intelligently and innovate in ways that were previously impossible. Learn more and get started with GitHub CopilotReimagining App Modernization for the Era of AI
This blog highlights the key announcements and innovations from Microsoft Build 2025. It focuses on how AI is transforming the software development lifecycle, particularly in app modernization. Key topics include the use of GitHub Copilot for accelerating development and modernization, the introduction of Azure SRE agent for managing production systems, and the launch of the App Modernization Guidance to help organizations modernize their applications with AI-first design. The blog emphasizes the strategic approach to modernization, aiming to reduce complexity, improve agility, and deliver measurable business outcomes
Streamline & Modernise ASP.NET Auth: Moving enterprise apps from IIS to App Service with Easy Auth
Introduction When modernising your enterprise ASP.NET (.NET Framework) or ASP.NET Core applications and moving them from IIS over to Azure App Service, one of the aspects you will have to take into consideration is how you will manage authentication (AuthN) and authorisation (AuthZ). Specifically, for applications that leverage on-premises auth mechanisms such as Integrated Windows Authentication, you will need to start considering more modern auth protocols such as OpenID Connect/OAuth which are more suited to the cloud. Fortunately, App Service includes built-in authentication and authorisation support also known as 'Easy Auth', which requires minimal to zero code changes. This feature is integrated into the platform, includes a built-in token store, and operates as a middleware running the AuthN logic outside of your code logic, as illustrated by the image below:- More information on how EasyAuth works can be found here. Easy Auth supports several providers as illustrated above, but in this blog we will purely focus on using Entra ID (formerly known as Azure Active Directory) as the provider. It also assumes all of the Active Directory users have been synced up to Entra ID. With a few clicks, you can enable Entra ID authentication across any of your web, mobile or API apps in App Service, restrict which tenants or even specific identities are allowed access – all without touching code. This can be quite powerful in many scenarios, such as when you do not have access to the source control to implement your own auth logic, reducing the maintenance overhead of maintaining libraries or simply want a quick path to apply auth across your apps. For more detailed scenarios and comparison on when it makes sense using Easy Auth versus other authentication methods can be found here. Setting up Easy Auth Let’s see Easy Auth in action. As you can see below I have a sample ASP.NET app hosted on App Service which is accessible without any authentication:- Now let’s demonstrate how quickly it is to setup Easy Auth for my app:- 1) I navigated to my App Service resource within the Azure Portal 2) I went to Authentication and used the below configuration o Selected Microsoft as the Identity provider o Workforce configuration (current tenant) o Create a new app registration (appropriate Entra ID roles are required) o Entra ID app name:- sot-easyauth o Client secret expiry:- 180 days (this means I must renew the secret in advance of the 180 days otherwise my app/authentication will fail to function upon expiry causing downtime). o Allow requests only from this application itself. o Current tenant – Single tenant (i.e users outside of my tenant will be denied access) o Identity requirement:- Allow requests from any identity o Restrict access:- Require authentication (this will require authentication across my whole app, whereas “Allow unauthenticated access” means it is up to my app to decide when authentication is required). o HTTP 302 Found redirect (redirects unauthenticated users to the login page rather than just a page stating 401 unauthorised for example). o Token store:- Enabled (also allows the app to have access to the token). 3) For permissions, I left the default User.Read Graph API permission selected. More information on the different permissions can be found here. Now if I go back to the app and refresh the page again, I am redirected to the login page which is surfaced by the Easy Auth middleware:- Only after successful authentication, will I be able to see the Welcome page again:- Now that is pretty impressive, but you might want to go even further and have questions such as: how will my app know who’s logged in? How can I access the claims? How do I perform more granular AuthZ? Well for starters, Easy Auth essentially creates the claims in the incoming token and exposes them to your app as request headers which your app can then leverage to interpret accordingly. The list of headers can be found here. Typically, you will be tasked with creating custom logic to decode and interpret these claims, but with the likes of ASP.NET (.NET Framework), App Service can populate the claims of the authenticated user without additional code logic. However for ASP.NET Core this does not hold true. Thus, given the approach differs between ASP.NET (.NET Framework) and ASP.NET Core (starting from .NET Core), I will split these up into two different sections after touching upon AuthZ and Entra ID app roles. AuthZ and Entra ID App Roles If your IIS ASP.NET app leverages Windows Authentication for AuthN, but your app manages AuthZ itself, perhaps by mapping the domain credentials (e.g. CONTOSO\Sam) to specific AuthZ roles stored in somewhere like a database and remains a requirement to do, you can achieve a similar outcome by using the claims provided by Easy Auth. However, it is not recommended to use fields such as domain credentials, e-mail or UPN (e.g. [email protected]) given such attributes can change and even be re-used over time. For example, an employee called Dan Long has the UPN of [email protected] leaves the company and another employee with the same name joins the company and is assigned the same UPN [email protected] – potentially giving unauthorised access to resources belonging to the former employee. Instead you may consider using the oid (i.e objectId), which is a globally unique GUID that identifies the user across applications within a single tenant. You might also consider pairing oid with tid (i.e tenant ID) for sharding/routing if required. A note for multi-tenancy applications: the same user that exists in different tenants will have a different oid. More information on how to reliably identify a user and the different claim types available can be found here. Alternatively, if the built-in authorisation policies do not suffice, you can leverage Entra ID app roles to apply authorisation within your ASP.NET App, which we will cover in more depth further down below. For demonstration purposes, I have created an app role called Member in my Entra ID App Registration and assigned the Entra ID group “Contoso EA Members” to this role via the associated Entra ID Enterprise Application, which my identity is part of as shown below:- I am leveraging said role to restrict only the role Member from being able to access the Member Area page (more on this further down). More information on creating your own Entra ID app roles can be found here. ASP.NET (.NET Framework) claims and Entra ID App roles For ASP.NET 4.6 apps, App Service populates the user’s claims through ClaimsPrincipal.Current, which means you can easily reference the claims without additional logic. I have created sample code which demonstrates this here, and the output of this in App Service can be found below:- You will notice Easy Auth has picked up my Entra ID app role called Member under claim type roles. In the screenshot and sample, you will notice I have a link located on the top nav bar called Member Area which is guarded by an [Authorize] tag to restrict only members with the role Member access. Unfortunately, at this stage, if we were to access the page it will return with 401 Access Denied, regardless of my identity having the appropriate app role. The reason behind this, is because ASP.NET is looking for the claim type “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” instead of “role”. Fortunately, Easy Auth can be configured to display the long claim name instead by configuring the Environment Variable WEBSITE_AUTH_USE_LEGACY_CLAIMS to False, as shown in the below screenshot:- After the change, if I logout and back in again, I will see this being reflected back into my application and the Member Area page will grant me access as shown in the screenshots below:- Voila, we now have claims and Entra ID app roles working within our ASP.NET application. ASP.NET Core claims and Entra ID App roles Out-of-the-box, Easy Auth does not support populating ASP.NET Core with the current user’s authentication context like it does for ASP.NET (.NET Framework) with ClaimsPrincipal. However, this can be achieved by using the nuget package Microsoft.Identity.Web which has built-in capability to achieve this. What I did was as follows:- 1) Installed the nuget package Microsoft.Identity.Web into my solution. 2) In my Program.cs file, I loaded in the library:- builder.Services.AddMicrosoftIdentityWebAppAuthentication(builder.Configuration); 3) I also added app.UseAuthorization() after app.UseAuthentication() app.UseAuthentication(); After these changes, User.Identities will now be populated with the claims, and the [Authorize] tag will work permitting only the role Member when visiting the Member Area page. The full sample code can be found here. Unlike with ASP.NET (.NET Framework), the downside with this approach is the added responsibility of managing an additional library (Microsoft.Identity.Web). Conclusion App Service Easy Auth can provide a streamlined and efficient way to manage authentication and authorisation for your ASP.NET applications. By leveraging Easy Auth, you can apply modern auth protocols with minimal to zero code changes. The built-in support for various identity providers, including Entra ID, can help developers implement flexible and robust auth mechanisms. As demonstrated, Easy Auth simplifies the process of integrating authentication and authorisation into your applications, making it an valuable tool for modernising enterprise apps. Good to know and additional resources Limitations of Entra ID app roles. For example “A user, group, or service principal can have a maximum of 1,500 app role assignment”:- Service limits and restrictions - Microsoft Entra ID | Microsoft Learn. You can leverage Azure Policy to audit across the organisation when App Service does not have Easy Auth enabled by turning on “App Service apps should have authentication enabled”:- Built-in policy definitions for Azure App Service - Azure App Service | Microsoft Learn. Work with User Identities in AuthN/AuthZ - Azure App Service | Microsoft Learn Configure Microsoft Entra Authentication - Azure App Service | Microsoft Learn Work with OAuth Tokens in AuthN/AuthZ - Azure App Service | Microsoft LearnKeep Your Azure Functions Up to Date: Identify Apps Running on Retired Versions
Running Azure Functions on retired language versions can lead to security risks, performance issues, and potential service disruptions. While Azure Functions Team notifies users about upcoming retirements through the portal, emails, and warnings, identifying affected Function Apps across multiple subscriptions can be challenging. To simplify this, we’ve provided Azure CLI scripts to help you: ✅ Identify all Function Apps using a specific runtime version ✅ Find apps running on unsupported or soon-to-be-retired versions ✅ Take proactive steps to upgrade and maintain a secure, supported environment Read on for the full set of Azure CLI scripts and instructions on how to upgrade your apps today! Why Upgrading Your Azure Functions Matters Azure Functions supports six different programming languages, with new stack versions being introduced and older ones retired regularly. Staying on a supported language version is critical to ensure: Continued access to support and security updates Avoidance of performance degradation and unexpected failures Compliance with best practices for cloud reliability Failure to upgrade can lead to security vulnerabilities, performance issues, and unsupported workloads that may eventually break. Azure's language support policy follows a structured deprecation timeline, which you can review here. How Will You Know When a Version Is Nearing its End-of-Life? The Azure Functions team communicates retirements well in advance through multiple channels: Azure Portal notifications Emails to subscription owners Warnings in client tools and Azure Portal UI when an app is running on a version that is either retired, or about to be retired in the next 6 months Official Azure Functions Supported Languages document here To help you track these changes, we recommend reviewing the language version support timelines in the Azure Functions Supported Languages document. However, identifying all affected apps across multiple subscriptions can be challenging. To simplify this process, I've built some Azure CLI scripts below that can help you list all impacted Function Apps in your environment. Linux* Function Apps with their language stack versions: az functionapp list --query "[?siteConfig.linuxFxVersion!=null && siteConfig.linuxFxVersion!=''].{Name:name, ResourceGroup:resourceGroup, OS:'Linux', LinuxFxVersion:siteConfig.linuxFxVersion}" --output table *Running on Elastic Premium and App Service Plans Linux* Function Apps on a specific language stack version: Ex: Node.js 18 az functionapp list --query "[?siteConfig.linuxFxVersion=='Node|18'].{Name:name, ResourceGroup:resourceGroup, OS: 'Linux', LinuxFxVersion:siteConfig.linuxFxVersion}" --output table *Running on Elastic Premium and App Service Plans Windows Function Apps only: az functionapp list --query "[?!contains(kind, 'linux')].{Name:name, ResourceGroup:resourceGroup, OS:'Windows'}" --output table Windows Function Apps with their language stack versions: az functionapp list --query "[?!contains(kind, 'linux')].{name: name, resourceGroup: resourceGroup}" -o json | ConvertFrom-Json | ForEach-Object { $appSettings = az functionapp config appsettings list -n $_.name -g $_.resourceGroup --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" -o json | ConvertFrom-Json $siteConfig = az functionapp config show -n $_.name -g $_.resourceGroup --query "{powerShellVersion: powerShellVersion, netFrameworkVersion: netFrameworkVersion, javaVersion: javaVersion}" -o json | ConvertFrom-Json $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value $version = switch($runtime) { 'node' { ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value } 'powershell' { $siteConfig.powerShellVersion } 'dotnet' { $siteConfig.netFrameworkVersion } 'java' { $siteConfig.javaVersion } default { 'Unknown' } } [PSCustomObject]@{ Name = $_.name ResourceGroup = $_.resourceGroup OS = 'Windows' Runtime = $runtime Version = $version } } | Format-Table -AutoSize Windows Function Apps running on Node.js runtime: az functionapp list --query "[?!contains(kind, 'linux')].{name: name, resourceGroup: resourceGroup}" -o json | ConvertFrom-Json | ForEach-Object { $appSettings = az functionapp config appsettings list -n $_.name -g $_.resourceGroup --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" -o json | ConvertFrom-Json $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value if ($runtime -eq 'node') { $version = ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value [PSCustomObject]@{ Name = $_.name ResourceGroup = $_.resourceGroup OS = 'Windows' Runtime = $runtime Version = $version } } } | Format-Table -AutoSize Windows Function Apps running on a specific language version: Ex: Node.js 18 az functionapp list --query "[?!contains(kind, 'linux')].{name: name, resourceGroup: resourceGroup}" -o json | ConvertFrom-Json | ForEach-Object { $appSettings = az functionapp config appsettings list -n $_.name -g $_.resourceGroup --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" -o json | ConvertFrom-Json $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value $nodeVersion = ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value if ($runtime -eq 'node' -and $nodeVersion -eq '~18') { [PSCustomObject]@{ Name = $_.name ResourceGroup = $_.resourceGroup OS = 'Windows' Runtime = $runtime Version = $nodeVersion } } } | Format-Table -AutoSize All windows Apps running on unsupported language runtimes: (as of March 2025) az functionapp list --query "[?!contains(kind, 'linux')].{name: name, resourceGroup: resourceGroup}" -o json | ConvertFrom-Json | ForEach-Object { $appSettings = az functionapp config appsettings list -n $_.name -g $_.resourceGroup --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" -o json | ConvertFrom-Json $siteConfig = az functionapp config show -n $_.name -g $_.resourceGroup --query "{powerShellVersion: powerShellVersion, netFrameworkVersion: netFrameworkVersion}" -o json | ConvertFrom-Json $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value $version = switch($runtime) { 'node' { $nodeVer = ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value if ([string]::IsNullOrEmpty($nodeVer)) { 'Unknown' } else { $nodeVer } } 'powershell' { $siteConfig.powerShellVersion } 'dotnet' { $siteConfig.netFrameworkVersion } default { 'Unknown' } } # Check if runtime version is unsupported $isUnsupported = switch($runtime) { 'node' { $ver = $version -replace '~','' [double]$ver -le 16 } 'powershell' { $ver = $version -replace '~','' [double]$ver -le 7.2 } 'dotnet' { $ver = $siteConfig.netFrameworkVersion $ver -notlike 'v7*' -and $ver -notlike 'v8*' } default { $false } } if ($isUnsupported) { [PSCustomObject]@{ Name = $_.name ResourceGroup = $_.resourceGroup OS = 'Windows' Runtime = $runtime Version = $version } } } | Format-Table -AutoSize Take Action Now By using these scripts, you can proactively identify and update Function Apps before they reach end-of-support status. Stay ahead of runtime retirements and ensure the reliability of your Function Apps. For step-by-step instructions to upgrade your Function Apps, check out the Azure Functions Language version upgrade guide. For more details on Azure Functions' language support lifecycle, visit the official documentation. Have any questions? Let us know in the comments below!Get Ready for .NET Conf: Focus on Modernization
We’re excited to announce the topics and speakers for .NET Conf: Focus on Modernization, our latest virtual event on April 22-23, 2025! This event features live sessions from .NET and cloud computing experts, providing attendees with the latest insights into modernizing .NET applications, including technical upgrades, cloud migration, and tooling advancements. To get ready, visit the .NET Conf: Focus on Modernization home page and click Add to Calendar so you can save the date on your calendar. From this page, on the day of the event you’ll be able to join a live stream on YouTube and Twitch. We will also make the source code for the demos available on GitHub and the on-demand replays will be available on our YouTube channel. Learn more: https://focus.dotnetconf.net/ Why attend? In the fast-changing technological environment we now find ourselves, it has never been more urgent to modernize enterprise .NET applications to maintain competitiveness and stay ahead of the next innovation. Updating .NET applications for the cloud is a major business priority and involves not only technical upgrades and cloud migration, but also improvements in tooling, processes, and skills. At this event, you will get the end to end insights across latest tools, innovations, and best practices for successful .NET modernization. What can developers expect? The event will run live for up to five hours each day, covering different aspects of .NET modernizations. Scott Hanselman will set the tone for day one with discussion of the experiences and processes to modernize .NET applications in the era of AI. This will be followed by expert sessions on upgrading .NET apps and modernizing both your apps and data to the cloud. Day two will soar higher into the clouds, with sessions to help with cloud migration, cloud development, and infusing AI into your apps. You can interact with experts and ask questions to deepen your expertise, as we broadcast live on YouTube, or Twitch. Recordings of all sessions will be available with materials after the event. Agenda Here’s a quick snapshot of the schedule. Things may change, and we recommend that you please visit the event home page for the latest agenda and session times: https://focus.dotnetconf.net/agenda Day 1 – April 22, Tuesday Time (PDT) Session 8:00 am Modernizing .NET: Future-ready applications in the era of AI Scott Hanselman, Chet Husk, McKenna Barlow 9:00 am Deep dive into the upcoming AI-assisted tooling to upgrade .NET apps Chet Husk, McKenna Barlow 10:00 am Use Reliable Web App patterns to confidently replatform your web apps Pablo Lopes 11:00 am Modernize Data-Driven Apps (No AI Needed) Jerry Nixon 12:00 pm Modernize from ASP.NET to ASP.NET Core: The Future is Now Taylor Southwick Day 2 – April 23, Wednesday Time (PDT) Session 8:00 am Unblock .NET modernization with AI-assisted app and code assessment tools Michael Yen-Chi Ho 9:00 am Cloud development doesn't have to be painful thanks to .NET Aspire Maddy Montaquila (Leger) 10:00 am Introducing Artificial Intelligence to your application Jordan Matthiesen 11:00 am Modernizing your desktop: From WinForms to Blazor, Azure, and AI Santiago Arango Toro Save the Date! .NET Conf: Focus on Modernization is a free, two-day livestream event that you won’t want to miss. Tune in on April 22 and 23, 2025, ask questions live, and learn how to get your .NET applications ready for the AI revolution. Save the date! Stay tuned for more updates and detailed session information. We can’t wait to see you there!Connect Azure SQL Server via System Assigned Managed Identity under ASP.NET
TOC Why we use it Architecture How to use it References Why we use it This tutorial will introduce how to integrate Microsoft Entra with Azure SQL Server to avoid using fixed usernames and passwords. By utilizing System-assigned managed identities as a programmatic bridge, it becomes easier for Azure-related PaaS services (such as Container Apps) to communicate with the database without storing connection information in plain text. Architecture I will introduce each service or component and their configurations in subsequent chapters according to the order of A-C: A: The company's account administrator needs to create or designate a user as the database administrator. This role can only be assigned to one person within the database and is responsible for basic configuration and the creation and maintenance of other database users. It is not intended for development or actual system operations. B: The company's development department needs to create a Container App (or other service) as the basic unit of the business system. Programmers within this unit will write business logic (e.g., accessing the database) and deploy it here. C: The company's data department needs to create or maintain a database and designate Microsoft Entra as the only login method, eliminating other fixed username/password combinations. How to use it A: As this article does not dive into the detailed configuration of Microsoft Entra, it will only outline the process. The company's account administrator needs to create or designate a user as the database administrator. In this example, we will call this user "cch," and the account, "cch@thexxxxxxxxxxxx" will be used in subsequent steps. B-1: In this example, we can create a Container App with any SKU/region. Please note that during the initial setup, we will temporarily use the nginx:latest image from docker.io. After creating our own ASP.NET image, we will update it accordingly. For testing convenience, please enable Ingress traffic and allow requests from all regions. Once the Container App has been created, please enable the System Assigned Managed Identity. Lastly, please make a note of your App Name (e.g., mine is az-1767-aca) as we will use it in the following steps. C-1: Create a database/SQL server. During this process, you need to specify the user created in Step A as the database administrator. Please note that to select "Microsoft Entra-only authentication." In this mode, the username/password will no longer be used. Then, click on "Next: Networking." Microsoft Entra and Username & Password login methods are selected, for security reasons, it is strongly recommended to choose Microsoft Entra Only. The Username & Password option will not be used in this tutorial.) Since this article does not cover the detailed network configuration of the database, temporarily allow public access during the tutorial. Use the default values for other settings, click on "Review + Create," and then click "Create" to finish the setup. During this process, you need to specify the system-assigned managed identity created in Step B as the entity that will actually operate the database. And leave it default from the rest of the parts, and finally create the Database. C-2: After the database has created, you can log in using the identity "cch@thexxxxxxxxxxxx" you've get from Step A which is the database administrator. Open a PowerShell terminal and using the "cch" account, enter the following command to log in to SQL Server. You will need to change the <text> to follow your company's naming conventions. sqlcmd -S <YOUR_SERVER_NAME>.database.windows.net -d <YOUR_DB_NAME> -U <YOUR_FULL_USER_EMAIL> -G You will be prompt for a 2 step verification. dentities setup from Step B. First, we will introduce the method for the system-assigned managed identity. The purpose of the commands is to grant database-related operational permissions to the newly created user. This is just an example. In actual scenarios, you should follow your company's security policies and make the necessary adjustments accordingly. Please enter the following command. CREATE USER [<YOUR_APP_NAME>] FROM EXTERNAL PROVIDER; USE [<YOUR_DB_NAME>]; EXEC sp_addrolemember 'db_owner', '<YOUR_APP_NAME>'; For testing purposes, we will create a test table, and insert some data. CREATE TABLE TestTable ( Column1 INT, Column2 NVARCHAR(100) ); INSERT INTO TestTable (Column1, Column2) VALUES (1, 'First Record'); INSERT INTO TestTable (Column1, Column2) VALUES (2, 'Second Record'); B-2: Developers can now start building the Docker image. In my sample development environment, I'm using .NET 8.0. Run the following command in your development environment to create a Hello World project: dotnet new web -n WebApp --no-https This command will generate many files used for the project. You will need to modify both Program.cs and WebApp.csproj. using Microsoft.Data.SqlClient; var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); app.MapGet("/", async context => { var response = context.Response; var connectionString = "Server=az-1767-dbserver.database.windows.net;Database=az-1767-db;Authentication=ActiveDirectoryMsi;TrustServerCertificate=True;"; await response.WriteAsync("Hello World\n\n"); try { using var conn = new SqlConnection(connectionString); await conn.OpenAsync(); var cmd = new SqlCommand("SELECT Column1, Column2 FROM TestTable", conn); using var reader = await cmd.ExecuteReaderAsync(); while (await reader.ReadAsync()) { var line = $"{reader.GetInt32(0)} - {reader.GetString(1)}"; await response.WriteAsync(line + "\n"); } } catch (Exception ex) { await response.WriteAsync($"[Error] {ex.Message}"); } }); app.Run("http://0.0.0.0:80"); <Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <Nullable>enable</Nullable> <ImplicitUsings>enable</ImplicitUsings> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.Data.SqlClient" Version="5.1.4" /> </ItemGroup> </Project> Please note the connectionString in Program.cs. The string must follow a specific format — you’ll need to replace az-1767-dbserver and az-1767-db with your own server and database names. After making the modifications, run the following command in the development environment. It will compile the project into a DLL and immediately run it (press Ctrl+C to stop). dotnet run Once the build is complete, you can package the entire project into a Docker image. Create a Dockerfile in the root of your project. FROM mcr.microsoft.com/dotnet/sdk:8.0 # Install ODBC Driver RUN apt-get update \ && apt-get install -y unixodbc odbcinst unixodbc-dev curl vim \ && curl -sSL -O https://packages.microsoft.com/debian/12/prod/pool/main/m/msodbcsql18/msodbcsql18_18.5.1.1-1_amd64.deb \ && ACCEPT_EULA=Y DEBIAN_FRONTEND=noninteractive dpkg -i msodbcsql18_18.5.1.1-1_amd64.deb \ && rm msodbcsql18_18.5.1.1-1_amd64.deb # Setup Project Code RUN mkdir /WebApp COPY ./WebApp /WebApp # OTHER EXPOSE 80 CMD ["dotnet", "/WebApp/bin/Debug/net8.0/WebApp.dll"] In this case, we are using mcr.microsoft.com/dotnet/sdk:8.0 as the base image. To allow access to Azure SQL DB, you’ll also need to install the ODBC driver in the image. Use the following command to build the image and push it to your Docker Hub (docker.io). Please adjust the image tag, for example az-1767-aca:202504091739 can be renamed to your preferred version, and replace theringe with your own Docker Hub username. docker build -t az-1767-aca:202504091739 . --no-cache docker tag az-1767-aca:202504091739 theringe/az-1767-aca:202504091739 docker push theringe/az-1767-aca:202504091739 After building and uploading the image, go back to your Container App and update the image configuration. Once the new image is applied, visit the app’s homepage and you’ll see the result. References: Connect Azure SQL Server via User Assigned Managed Identity under Django | Microsoft Community Hub Managed identities in Azure Container Apps | Microsoft Learn Azure Identity client library for Python | Microsoft Learn
Understanding 'Always On' vs. Health Check in Azure App Service
The 'Always On' feature in Azure App Service helps keep your app warm by ensuring it remains running and responsive, even during periods of inactivity with no incoming traffic. As this feature pings to root URI after every 5 minutes. On Other hand Health-check feature helps pinging configured path every minute to monitor the application availability on each instance. What is 'Always On' in Azure App Service? The Always On feature ensures that the host process of your web app stays running continuously. This results in better responsiveness after idle periods since the app doesn’t need to cold boot when a request arrives. How to enable Always On: Navigate to the Azure Portal and open your Web App. Go to Configuration > General Settings. Toggle Always On to On. What is Health Check in Azure App Service? Health check increases your application's availability by rerouting requests away from instance where application is marked unhealthy and replacing instances if they remain unhealthy. How to enable Health-Check: Navigate to the Azure Portal and open your Web App. Under Monitoring, select Health check. Select Enable and provide a valid URL path for your application, such as /health or /api/health. Select Save. So, is it still necessary to enable the 'Always On' feature when Health Check is already pinging your application every minute? -> Yes, please find below explanation for the same. Test App scenario: Health Check enabled (pointing to /health_check path) and Always On disabled. Started the app and sent some user requests. Observations from the Test: After the application starts up, health check pings begin following the end user's request. Please find below table representing Health-check pings following user's request to root URI. Time Bucket URL Status Request Count 2025-03-20 07:00:00.0000000 / 200 6 2025-03-20 07:00:00.0000000 /health_check 200 30 2025-03-20 07:30:00.0000000 /health_check 200 30 Subsequent Health-check pings will continue, even in the absence of user requests. However, after restarting the app and in the absence of any user requests, we observed that Health Check requests were not initiated. This indicates that Health Check does not start automatically unless application is actively running and serving requests. Conclusion: Always On ensures that the app is proactively kept warm by sending root URI pings, even post-restart. The health-check feature is useful for monitoring application availability when the application is active. However, after a restart, if the application isn't active due to a lack of requests, Health-check pings won't initiate. Therefore, it is highly recommended to enable Always On, particularly for applications that need continuous availability and to avoid application process unload events. Recommendation: Enable Always On alongside Health Check to ensure optimal performance and reliability.What's New in Azure App Service at Ignite 2024
Learn about the GA of sidecar extensibility on Linux and see team members demonstrating the latest tools for AI assisted web application migration and modernization as well as the latest updates to Java JBoss EAP on Azure App Service. Team members will also demonstrate integrating the Phi-3 small language model with a web application via the new sidecar extensibility using existing App Service hardware! Also new for this year’s Ignite, many topics that attendees see in App Service related sessions are also available for hands-on learning across multiple hands-on labs (HoLs). Don’t just watch team members demonstrating concepts on-stage, drop by one of the many HoL sessions and test drive the functionality yourself! Azure App Service team members will also be in attendance at the Expert Meetup area on the third floor in the Hub – drop by and chat if you are attending in-person! Additional demos, presentations and hands-on labs covering App Service are listed at the end of this blog post for easy reference. Sidecar Extensibility GA for Azure App Service on Linux Sidecar extensibility for Azure App Service on Linux is now GA! Linux applications deployed from source-code as well as applications deployed using custom containers can take advantage of sidecar extensibility. Sidecars enable developers to attach additional capabilities like third-party application monitoring providers, in-memory caches, or even local SLM (small language model) support to their applications without having to bake that functionality directly into their applications. Developers can configure up to four sidecar containers per application, with each sidecar being associated with its own container registry and (optional) startup command. Examples of configuring an OpenTelemetry collector sidecar are available in the documentation for both container-based applications and source-code based applications. There are also several recent blog posts demonstrating additional sidecar scenarios. One example walks through using a Redis cache sidecar as an in-memory cache to accelerate data retrieval in a web application (sample code here). Another example demonstrates adding a sidecar containing the Phi-3 SLM to a custom container web application (sample code here). Once the web app is running with the SLM sidecar, Phi-3 processes text prompts directly on the web server without the need to call remote LLMs or host models on scarce GPU hardware. Similar examples for source deployed applications are available in the Ignite 2024 hands on lab demonstrating sidecars. Exercise three walks through attaching an OTel sidecar to a source-code based application, and exercise four shows how to attach a Phi-3 sidecar to a source-code based application. Looking ahead to the future, App Service will be adding “curated sidecars” to the platform to make it easier for developers to integrate common sidecar scenarios. Development is already underway to include options for popular third-party application monitoring providers, Redis cache support, as well as a curated sidecar encapsulating the Phi-3 SLM example mentioned earlier. Stay tuned for these enhancements in the future! If you are attending Microsoft Ignite 2024 in person, drop by the theater session “Modernize your apps with AI without completely rewriting your code” (session code: THR 614) which demonstrates using sidecar extensibility to add Open Telemetry monitoring as well as Phi-3 SLM support to applications on App Service for Linux! .NET 9 GA, JBoss EAP and More Language Updates! With the recent GA of .NET 9 last week developers can deploy applications running .NET 9 GA on both Windows and Linux variants of App Service! Visual Studio, Visual Studio Code, Azure DevOps and GitHub Actions all support building and deploying .NET 9 applications onto App Service. Start a new project using .NET 9 or upgrade your existing .NET applications in-place and take advantage of .NET 9! For JBoss EAP on App Service for Linux, customers will soon be able to bring their existing JBoss licenses with them when moving JBoss EAP workloads onto App Service for Linux. This change will make it easier and more cost effective than ever for JBoss EAP customers to migrate existing workloads to App Service, including JBoss versions 7.3, 7.4 and 8.0! As a quick reminder, last month App Service also announced reduced pricing for JBoss EAP licenses (for net-new workloads) as well as expanded hardware support (both memory-optimized and Free tier are now supported for JBoss EAP applications). App Service is planning to release both Node 22 and Python 3.13 onto App Service for Linux with expected availability in December! Python 3.13 is the latest stable Python release which means developers will be able to leverage this version with confidence given long term support runs into 2029. Node 22 is the latest active LTS release of Node and is a great version for developers to adopt with its long-term support lasting into 2026. A special note for Linux Python developers, App Service now supports “auto-instrumentation” in public preview for Python versions 3.8 through 3.12. This makes it trivial for source-code based Python applications to enable Application Insights monitoring for their applications by simply turning the feature “on” in the Azure Portal. If you ever thought to yourself that it can be a hassle setting up application monitoring and hence find yourself procrastinating, this is the monitoring feature for you! Looking ahead just a few short weeks until December, App Service also plans to release PHP 8.4 for developers on App Service for Linux. This will enable PHP developers to leverage the latest fully supported PHP release with an expected support cycle stretching into 2028. For WordPress customers Azure App Service has added support for managed identities when connecting to MySQL database as well as storage accounts. The platform has also transitioned WordPress from Alpine Linux to Debian, aligning with App Service for Linux to offer a more secure platform. Looking ahead, App Service is excited to introduce some new features by the end of the year, including an App Service plugin for WordPress! This plugin will enable users to manage WordPress integration with Azure Communication Services email, set up Single Sign-On using Microsoft Entra ID, and diagnose performance bottlenecks. Stay tuned for upcoming WordPress announcements! End-to-End TLS & Min TLS Cipher Suite are now GA End-to-end TLS encryption for public multi-tenant App Service is now GA! When E2E TLS is configured, traffic between the App Service frontends and individual workers is secured using a platform supplied TLS certificate. This additional level of security is available for both Windows and Linux sites using Standard SKU and above as well as Isolatedv2 SKUs. You can enable this feature easily in the Azure Portal by going to your resource, clicking the “Configuration” blade and turning the feature “On” as shown below: Configuration of the minimum TLS cipher suite for a web application is also GA! With this feature developers can choose from a pre-determined list of cipher suites. When a minimum cipher suite is selected, the App Service frontends will reject any incoming requests that use a cipher suite weaker than the selected minimum cipher suite. This feature is supported for both Windows and Linux applications using Basic SKU and higher as well as Isolatedv2 SKUs. You configure a minimum TLS cipher suite in the Azure Portal by going to the “Configuration” blade for a website and selecting “Change” for the Minimum Inbound TLS Cipher Suite setting. In the resulting blade (shown below) you can select the minimum cipher suite for your application: To learn more about these and other TLS features on App Service, please refer to the App Service TLS overview. AI-Powered Conversational Diagnostics Building on the Conversational Diagnostics AI-powered tool and the guided decision making path introduced in Diagnostic Workflows, the team has created a new AI-driven natural language-based diagnostics solution for App Service on Linux. The new solution brings together previous functionality to create an experience that comprehends user intent, selects the appropriate Diagnostic Workflow, and keeps users engaged by providing real-time updates and actionable insights through chat. Conversational Diagnostics also provides the grounding data that the generative AI back-end uses to produce recommendations thus empowering users to check the conclusions. The integration of Conversational Diagnostics and Diagnostic Workflows marks a significant advancement in the platform’s diagnostic capabilities. Stay tuned for more updates and experience the transformative power of Generative AI-driven diagnostics firsthand! App Service Migration and Modernization The team just recently introduced new architectural guidance around evolving and modernizing web applications with the Modern Web Application pattern for .NET and Java! This guidance builds on the Reliable Web App pattern for .NET and Java as well as the Azure Migrate application and code assessment tool. With the newly released Modern Web Application guidance, there is a well-documented path for migrating web applications from on-premises/VM deployments using the application and code assessment tool, iterating and evolving web applications with best practices using guidance from the Reliable Web App pattern, and subsequently going deeper on modernization and re-factoring following guidance from the Modern Web Application pattern. Best of all customers can choose to “enter” this journey at any point and progress as far down the modernization path as needed based on their unique business and technical requirements! As a quick recap on the code assessment tool, it is a guided experience inside of Visual Studio with GitHub Copilot providing actionable guidance and feedback on recommended changes needed to migrate applications to a variety of Azure services including Azure App Service. Combined with AI-powered Conversational Diagnostics (mentioned earlier), developers now have AI-guided journeys supporting them from migration all the way through deployment and runtime operation on App Service! Networking and ASE Updates As of November 1, 2024, we are excited to announce that App Service multi-plan subnet join is generally available across all public Azure regions! Multi-plan subnet join eases network management by reducing subnet sprawl, enabling developers to connect multiple app service plans to a single subnet. There is no limit to the number of app service plans that connect to a single subnet. However, developers should keep in mind the number of available IPs since tasks such as changing the SKU for an app service plan will temporarily double the number of IP addresses used in a connected subnet. For more information as well as examples on using multi-plan subnet join see the documentation! App Service also recently announced GA of memory optimized options for Isolatedv2 on App Service Environment v3. The new memory-optimized options range from two virtual cores with 16 GB RAM in I1mv2 (compared to two virtual cores, 8 GB RAM in I1v2) all the way up to 32 virtual cores with 256 GB RAM in I5mv2. The new plans are available in most regions. Check back regularly to see if your preferred region is supported. For more details on the technical specifications of these plans, as well as information on the complete range of tiers and plans for Microsoft Azure App Service, visit our pricing page. Using services such as Application Gateway and Azure Front Door with App Service as entry points for client traffic is a common scenario that many of our customers implement. However, when using these services together, there are integration challenges around the default cookie domain for HTTP cookies, including the ARRAffinity cookie used for session affinity. App Service collaborated with the Application Gateway team to introduce a simple solution that addresses the session affinity problem. App Service introduced a new session affinity proxy configuration setting in October which tells App Service to always set the hostname for outbound cookies based on the upstream hostname seen by Application Gateway or Azure Front Door. This simplifies integration with a single-click experience for App Service developers who front-end their websites using one of Azure’s reverse proxies, and it solves the challenge of round-tripping the ArrAffinity cookie when upstream proxies are involved. Looking ahead to early 2025, App Service will shortly be expanding support for IPv6 to include both inbound and outbound connections (currently only inbound connections are supported). The current public preview includes dual-stack support for both IPv4 and IPv6, allowing for a smooth transition and compatibility with existing systems. Read more about the latest status of the IPv6 public preview on App Service here ! Lastly, the new application naming and hostname convention that was rolled out a few months earlier for App Service is now GA for App Service. The platform has also extended this new naming convention to Azure Functions where it is now available in public preview for newly created functions. To learn more about the new naming convention and the protection it provides against subdomain takeover take a look at the introductory blog post about the unique default hostname feature. Upcoming Availability Zone Improvements New Availability Zone features are currently rolling out that will make zone redundant App Service deployments more cost efficient and simpler to manage in early 2025! The platform will be changing the minimum requirement for enabling Availability Zones to two instances instead of three, while still maintaining a 99.99% SLA. Many existing app service plans with two or more instances will also automatically become capable of supporting Availability Zones without requiring additional setup. Additionally, the zone redundant setting will be mutable throughout the life of an app service plan. This upcoming improvement will allow customers on Premium V2, Premium V3, or Isolated V2 plans, to toggle zone redundancy on or off as needed. Customers will also gain enhanced visibility into Availability Zone information, including physical zone placement and counts. As a sneak peek into the future, the screenshot below shows what the new experience will look like in the Azure Portal: Stay tuned for Availability Zone updates coming to App Service in early 2025! Next Steps Developers can learn more about Azure App Service at Getting Started with Azure App Service. Stay up to date on new features and innovations on Azure App Service via Azure Updates as well as the Azure App Service (@AzAppService) X feed. There is always a steady stream of great deep-dive technical articles about App Service as well as the breadth of developer focused Azure services over on the Apps on Azure blog. Azure App Service (virtually!) attended the recently completed November .Net Conf 2024. App Service functionality was featured showing a .NET 9.0 app using Azure Sql’s recently released native vector data type support that enables developers to perform hybrid text searches on Azure Sql data using vectors generated via Azure OpenAI embeddings! And lastly take a look at Azure App Service Community Standups hosted on the Microsoft Azure Developers YouTube channel. The Azure App Service Community Standup series regularly features walkthroughs of new and upcoming features from folks that work directly on the product! Ignite 2024 Session Reference (Note: some sessions/labs have more than one timeslot spanning multiple days). (Note: all times below are listed in Chicago time - Central Standard Time). Modernize your apps with AI without completely rewriting your code Modernize your apps with AI without completely rewriting your code [Note: this session includes a demonstration of the Phi-3 sidecar scenario] Wednesday, November 20 th 1:00 PM - 1:30 PM Central Standard Time Theater Session – In-Person Only (THR614) McCormick Place West Building – Level 3, Hub, Theater C Unlock AI: Assess your app and data estate for AI-powered innovation Unlock AI: Assess your app and data estate for AI-powered innovation Wednesday, November 20 th 1:15 PM – 2:00 PM Central Time McCormick Place West Building – Level 1, Room W183c Breakout and Recorded Session (BRK137) Modernize and scale enterprise Java applications on Azure Modernize and scale enterprise Java applications on Azure Thursday, November 21 st 8:30 AM - 9:15 AM Central Time McCormick Place West Building – Level 1, Room W183c Breakout and Recorded Session (BRK147) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Tuesday, November 19 th 1:15 PM - 2:30 PM Central Time McCormick Place West Building – Level 4, Room W475 Hands on Lab – In-Person Only (LAB408) Integrate GenAI capabilities into your .NET apps with minimal code changes Integrate GenAI capabilities into your .NET apps with minimal code changes [Note: Lab participants will be able to try out the Phi-3 sidecar scenario in this lab.] Wednesday, November 20 th 8:30 AM - 9:45 AM Central Time McCormick Place West Building – Level 4, Room W475 Hands on Lab – In-Person Only (LAB411) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Wednesday, November 20 th 6:30 PM - 7:45 PM Central Time McCormick Place West Building – Level 4, Room W470b Hands on Lab – In-Person Only (LAB408-R1) Integrate GenAI capabilities into your .NET apps with minimal code changes Integrate GenAI capabilities into your .NET apps with minimal code changes [Note: Lab participants will be able to try out the Phi-3 sidecar scenario in this lab.] Thursday, November 21 st 10:15 AM - 11:30 AM Central Time McCormick Place West Building – Level 1, Room W180 Hands on Lab – In-Person Only (LAB411-R1) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Friday, November 22 nd 9:00 AM – 10:15 AM Central Time McCormick Place West Building – Level 4, Room W474 Hands on Lab – In-Person Only (LAB408-R2)
