Generally Available: Transition to WS2012 / R2 ESUs enabled by Azure Arc from Volume Licensing
Customers that have enrolled in WS2012/ R2 ESUs through Volume Licensing for Year 1 can transition to Azure Arc for Year 2 of the program by specifying their Volume Licensing entitlements (Invoice Ids) in provisioning new Azure Arc WS2012/R2 ESU licenses. Extended Security Updates afford customers with critical security patches for end of support Windows Server 2012/R2 machines.Generally Available: Windows Server 2012 and 2012 R2 Extended Security Updates enabled by Azure Arc
Secure your End-of-Life Windows Server infrastructure on your own terms with Azure Arc. Benefit from the flexibility of a monthly Azure billed service and free access to Azure management services by leveraging Extended Security Updates enabled by Azure Arc for your Windows Server 2012 and 2012 R2 machines.The first Windows Server 2012/R2 ESU Patches are out! Are you protected?
Receive critical security patches for your WS2012/R2 machines enrolled in ESUs enabled by Azure Arc. Follow these detailed instructions outlining all of the enrollment and prerequisites, so you are protecting your EOL infrastructure.Episode 1: Onboarding Azure Arc at Scale | The Azure Arc Check-In
Once a month the Azure Arc team will release an episode covering a variety of topics. To request a topic or view additional episodes please visit: aka.ms/the-azure-arc-check-in Episode 1: Onboarding Azure Arc at Scale Scenario: Imagine your organization has 1,000 Windows and Linux servers spread across multiple locations. You want them all in Azure Arc, but first you need to deploy the Azure Connected Machine agent at scale. Try now in Azure aka.ms/aaci-episode1 Why onboarding strategy matters Interactive sign-in works well for testing and proof-of-concepts, but it quickly becomes impractical when you’re onboarding large server estates. At scale, organizations need a deployment model that can: Automate onboarding across many machines Align with existing management tooling Apply consistent configuration and governance from day one Minimize manual effort and human error This episode focuses on using non-interactive authentication and automation to onboard large server fleets efficiently. One of the key recommendations is to use a dedicated authentication mechanism designed for scale rather than relying on interactive administrator sign-ins. Onboard a Linux fleet with Ansible The Ansible deployment begins with an Ansible node that is already connected to Azure Arc. The deployment uses the credential on the Ansible node to deploy the Azure Connected Machine agent to the Linux fleet. To enable this, the managed identity of the Ansible node has the Azure Connected Machine Onboarding role in Azure assigned. Below are the steps for role assignment in the Azure portal: Open the resource group where the servers will be deployed. In Access control, add a role assignment. Select the Azure Connected Machine Onboarding role. Choose managed identities, select Machine - Azure Arc, and find the Ansible node. Review and assign the role. Configure the Ansible playbook With the permissions in place, the deployment uses three files: inventory.ini: Represents the machines configured by the playbook. arc-vars.yml: Contains non-secret configuration, including the resource group name, subscription and tenant IDs, location, and tags. arc-onboard.yml: References arc-vars.yml and configures the playbook to use managed identity, or MSI, for authentication. After the playbook runs, Ansible deploys the Azure Connected Machine agent to the Linux fleet. You can return to the resource group, refresh the view, and verify that your Linux machines appear as Azure Arc connected servers. Onboard Windows machines with Group Policy For Windows Server environments joined to Active Directory, Group Policy remains one of the simplest and most scalable deployment mechanisms. The process includes: Creating the required onboarding identity Preparing a shared location for deployment assets Downloading the Azure Arc GPO deployment package Generating a Group Policy Object with the required settings Linking that GPO to the appropriate organizational unit (OU) Allowing targeted servers to automatically onboard during policy refresh cycles For organizations that already manage Windows Server through Active Directory, this approach enables onboarding at scale without introducing additional management infrastructure. FAQs What is the best way to onboard servers to Azure Arc at scale? For large Windows and Linux server environments, use automated deployment with non-interactive authentication rather than signing in interactively on each machine. This approach lets you deploy the Azure Connected Machine agent consistently across many servers while reducing manual effort and human error. Azure Connected Machine Agent Deployment Options - Azure Arc Can I use Ansible to onboard Linux servers to Azure Arc? Yes. You can use an Azure Arc-enabled Ansible node to deploy the Azure Connected Machine agent across a Linux server fleet. In the approach demonstrated here, the Ansible node uses its managed identity, which is assigned the Azure Connected Machine Onboarding role, to authenticate the deployment. Connect machines to Azure Arc at scale using Ansible - Azure Arc Can I use Group Policy to onboard Windows servers to Azure Arc? Yes. Group Policy can automate Azure Arc onboarding for Windows Server machines that are joined to Active Directory. The process uses a Group Policy Object linked to the appropriate organizational unit, allowing targeted servers to onboard automatically during Group Policy refresh cycles. Connect machines at scale using Group Policy with a PowerShell script - Azure Arc What files are needed to onboard Linux servers to Azure Arc with Ansible? The Ansible deployment shown in this episode uses three files: inventory.ini to identify the target machines, arc-vars.yml to store non-secret configuration such as subscription, tenant, resource group, location, and tags, and arc-onboard.yml to run the onboarding playbook using managed identity authentication. Should I use Ansible or Group Policy for Azure Arc onboarding? Use Ansible when onboarding Linux servers in an environment that already uses Ansible playbooks and automation. Use Group Policy when onboarding domain-joined Windows servers managed through Active Directory. Both approaches help organizations automate Azure Connected Machine agent deployment by using tools already present in their server-management environment. Additional options are available for onboarding servers at scale. See Azure Connected Machine Agent deployment options.Microsoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube Migration Agent (Complete refactoring from BizTalk to Logic Apps): Bringing all your Integration workloads to Logic Apps Standard | Microsoft Community Hub We encourage customers to engage their Microsoft accounts team early to assess readiness, identify modernization opportunities, and explore assistance programs. Your Modernization Journey Starts Now BizTalk Server has played a foundational role in enterprise integration success for more than two decades. As you plan ahead, Microsoft is here to partner with you every step of the way, ensuring operational continuity today while unlocking innovation tomorrow. To begin your transition, please contact your Microsoft account team or visit our migration hub. Thank you for your continued trust in Microsoft and BizTalk Server. We look forward to partnering closely with you as you plan the future of your integration platforms. Frequently Asked Questions Do I need to migrate now? No. BizTalk Server 2020 is fully supported through April 11, 2028, with paid Extended Support available through April 9, 2030, for non-security hotfixes. CSS will continue providing their typical support. You have a long and predictable runway to plan your transition. Will there be a new BizTalk Server version? No. BizTalk Server 2020 is the final version of the product. What happens after April 9, 2030? BizTalk Server will reach End of Support, and security updates or technical assistance will no longer be provided. Workloads will continue running but without Microsoft servicing. Is paid support available past 2028? Yes. Paid extended support will be available through April 2030 for BizTalk Server 2020 customers looking for non-security hotfixes. CSS will continue to provide the typical support. What is the end of sale date for BizTalk Server? We will announce an end of sale date for BizTalk Server on July 2026. What about BizTalk Server 2016 or earlier versions? Those versions are already out of mainstream support. We strongly encourage moving directly to Logic Apps rather than upgrading to BizTalk Server 2020. Will Host Integration Server continue? Yes. Host Integration Server (HIS) 2028 will be released as a standalone product with its own lifecycle and support commitments. Can I reuse BizTalk Server artifacts in Logic Apps? Yes. Most of BizTalk maps, schemas, rules, assemblies, and custom code can be reused with minimal effort using Microsoft and partner migration tooling. We welcome feature requests here: https://aka.ms/logicappsneeds Does modernization require moving fully to the cloud? No. Logic Apps supports hybrid deployments for scenarios requiring local processing or regulatory compliance, and fully disconnected environments are under evaluation. More information of the Hybrid deployment model here: https://aka.ms/lahybrid. Does modernization unlock AI capabilities? Yes. Logic Apps enables AI-driven automations through Agent Loop, improving routing, decisioning, and operational intelligence. Where do I get planning support? Your Microsoft account team can assist with assessment and planning. Migration resources are also linked in this announcement to help you get started. Microsoft CorporationAzure Arc Server June Forum
Please find the recording for the monthly Azure Arc Server Forum on YouTube! During the June 2026 Azure Arc Server Forum, we discussed: Arc Server AI Agent assists with onboarding and troubleshooting through an integrated LLM with plans for surfacing the experience through Azure Copilot and in Azure Portal. Azure Arc Multicloud Connector Updates focused on both the Public Preview of the Google Cloud Platform (GCP) Connector and Public Preview of Azure Arc-enablement of detected EKS Clusters. WS 2016 ESU Updates with planned changes versus WS 2012 ESUs and expected timelines anticipating the WS 2016 end-of-support date of January 2027. Note, WS 2012 ESUs will end in October 2026. SQL 2016 ESU Updates discussed enrollment processes, licensing basics, and overall guidance with end-of-support in July 2026. To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/. For the latest agent release notes, check out What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn. We are skipping July and August, and will resume after summer holidays with the September forum to be held on Thursday, September 17 at 9:30 AM PST / 12:30 PM EST. Finally, I wanted to thank everyone for the attendance and community over the last few years, I will no longer be leading the community calls. Please stay in touch, and Mason Torres, Yunis Hussein, and Meagan McCrory from the Arc PM team will be taking the community forward. We look forward to you joining us, thank you!
Azure Local expands SAN capabilities with iSCSI support
As organizations modernize datacenters and accelerate migration from legacy virtualization platforms, flexibility in storage architecture has become a key requirement. Customers increasingly want to reuse existing storage investments, scale infrastructure independently, and choose the connectivity model that best fits their environment. Building on the general availability of Fibre Channel (FC) SAN support, Azure Local now introduces iSCSI SAN integration, extending disaggregated architecture support to IP-based storage networks. With support for both Fibre Channel and iSCSI, Azure Local provides customers greater flexibility in how they modernize and scale their infrastructure while maintaining an Azure-consistent management experience. Expanding disaggregated infrastructure iSCSI support enables organizations to: Leverage existing IP-based storage networks Deploy cost-efficient disaggregated architectures without FC dependency Scale compute and storage independently Maintain an Azure-consistent management experience Architecture and deployment Azure Local supports 6-adapter configurations to balance cost, performance, and resiliency: 6 adapters: enhanced performance and redundancy with dedicated iSCSI paths. Today, iSCSI follows a manual configuration flow during deployment. Azure Local Deployment Azure Local supports two SAN deployment approaches: Hybrid deployments (S2D + SAN) Customers can attach external SAN storage to existing Azure Local deployments while continuing to use Storage Spaces Direct (S2D) for platform storage. This approach enables organizations to incrementally adopt SAN while reusing existing storage investments. Disaggregated deployments (SAN-only) Customers can also deploy Azure Local using external SAN storage as the primary storage platform for both infrastructure and workloads. This enables: Independent scaling of compute and storage Fibre Channel or iSCSI connectivity Larger-scale infrastructure deployments Connected and disconnected deployment models Manage rising disk costs associated with hyperconverged architectures Additionally, customers can create local availability zones to align VM placement with physical infrastructure boundaries and support more granular workload placement. The deployment also validates connected SAN arrays against the supported vendor ecosystem, helping ensure a streamlined and fully supported experience. Accelerating infrastructure modernization Azure Migrate now supports migration to Azure Local deployments that use external SAN storage, including NTFS-based volumes. This allows organizations to modernize compute infrastructure while preserving existing storage investments. Customers can: Reuse existing SAN arrays and operational processes Minimize disruption during modernization projects Retain familiar storage architectures while adopting Azure Local Simplify migration from existing virtualization environments What's next iSCSI support represents another step in our broader vision for external storage on Azure Local. Our goal is to provide a comprehensive storage platform that spans deployment, operations, protection, and recovery. Looking ahead, we are investing in: Integration of iSCSI node configuration into cluster deployment to simplify the initial setup. Business Continuity and Disaster Recovery (BCDR) for SAN-backed workloads, including replication, failover, and failback capabilities between two external SAN attached or disaggregated Azure local clusters. Day-N storage management experiences that simplify monitoring, troubleshooting, and operational workflows. Replication management capabilities that provide visibility into recovery readiness, replication health, and workload mobility across environments. Expanding enterprise storage vendors ecosystem for Azure Local, helping customers adopt Azure Local while preserving their existing storage investments. Together, these investments will extend Azure Local beyond SAN connectivity and deployment to deliver a unified storage management experience across a broad ecosystem of enterprise storage solutions. Summary With iSCSI support, Azure Local now delivers a more complete SAN strategy—giving customers the flexibility to choose Fibre Channel or iSCSI, deploy hybrid or fully disaggregated architectures, and modernize infrastructure without abandoning existing storage investments. As we continue to invest in SAN management, replication, and disaster recovery, Azure Local is evolving into a comprehensive platform for enterprise storage and infrastructure modernization—from edge deployments to sovereign-scale datacenters.
Hybrid Logic Apps Deployment on Red Hat OpenShift
What makes OpenShift different? If you've done this on K3s or AKS, most of the flow is identical as mentioned in Set up your own infrastructure for Standard logic app workflows - Azure Logic Apps | Microsoft Learn. Two OpenShift specifics are worth flagging up front. First, SCCs: the default restricted-v2 policy blocks the elevated permissions the runtime and CSI driver need, so you grant the right SCCs before installing (Step 2). Second, DNS: OpenShift runs DNS through the openshift-dns operator rather than the kube-system/coredns you'd find on AKS, so the DNS setup targets that instead (Step 7). Prerequisites Requirement Notes Azure subscription With rights to create Arc resources, custom locations, and connected environments. Azure CLI Latest, with the connectedk8s, k8s-extension, customlocation, and containerapp extensions. OpenShift cluster Self-managed OpenShift (bare metal, datacenter, or Single-Node OpenShift), or ARO. oc logged in as a cluster-admin. Newer OCP is better (some storage options are GA only on 4.18+). Don't have one yet? See the install links under References section below A SMB file share a SMB file share discoverable from the cluster to store workflow artifacts Ingress / load balancer On self-managed OpenShift you provide the ingress IP yourself: an in-cluster LB (MetalLB or similar) or an external L4 LB in front of a NodePort. See Choose your ingress path below. (ARO provides it automatically.) Install/confirm the CLI extensions: az extension add --name connectedk8s az extension add --name k8s-extension az extension add --name customlocation az extension add --name containerapp Choose your ingress path (self-managed) Every app is reached through one shared Envoy ingress, and that ingress needs an IP clients can hit. A self-managed cluster has no cloud load balancer to hand one out, so this is the piece you provide. Two options work well; pick whichever fits your environment: Option How it works You set up Best when In-cluster load balancer A bare-metal LoadBalancer controller gives the envoy LoadBalancer service an IP from a pool on your node subnet. MetalLB is the common pick; kube-vip, Cilium, and OpenELB work the same way Install the controller + an address pool; envoy.serviceType=LoadBalancer You have a spare IP range on the node network and want a self-contained cluster External LB + NodePort Any external L4 load balancer forwards to a NodePort on every node. That can be an appliance (F5, NetScaler, HAProxy, a hardware VIP…) or an Azure Standard Load Balancer when your nodes are Azure VMs in the same region envoy.serviceType=NodePort; wire your LB → NodePort You already run a datacenter load balancer, or your cluster runs on Azure VMs Your choice affects exactly two later steps: the envoy.serviceType value in Step 4, and which IP you pass to --static-ip in Step 6. Nothing else changes. On ARO you can skip this section. Leave envoy.serviceType=LoadBalancer and the cloud controller assigns the EXTERNAL-IP for you; the rest of the guide is unchanged. Step 1: Connect your OpenShift cluster to Azure Arc Log in to OpenShift and confirm you're cluster-admin: oc login <api-url> -u kubeadmin oc whoami # should be able to run cluster-admin actions Connect the cluster to Arc: az connectedk8s connect --name <cluster> --resource-group <rg> Step 2: Install the SMB CSI driver helm repo add csi-driver-smb https://raw.githubusercontent.com/kubernetes-csi/csi-driver-smb/master/charts helm repo update helm install csi-driver-smb csi-driver-smb/csi-driver-smb \ --namespace kube-system --version v1.16.0 \ --set image.smb.repository=mcr.microsoft.com/oss/kubernetes-csi/csi-driver-smb Step 3: Grant the required SCCs (OpenShift-specific) The extension installs with Helm --atomic, so if any pod is denied byrestricted-v2 the entire install rolls back. Grant the SCCs to the install namespace's service accounts before installing: oc create namespace logicapps-aca-ns oc adm policy add-scc-to-group anyuid system:serviceaccounts:logicapps-aca-ns oc adm policy add-scc-to-group privileged system:serviceaccounts:logicapps-aca-ns oc adm policy add-scc-to-group hostnetwork system:serviceaccounts:logicapps-aca-ns Step 4: Install the Container Apps extension Now install the extension that turns the cluster into a Logic Apps host. The command is the same for every cluster; the only line that depends on your ingress choice is the last one, envoy.serviceType: az k8s-extension create \ --resource-group <rg> --cluster-name <cluster> \ --cluster-type connectedClusters --name logicapps-aca-extension \ --extension-type Microsoft.App.Environment \ --release-train stable --auto-upgrade-minor-version true --scope cluster \ --release-namespace logicapps-aca-ns \ --configuration-settings "Microsoft.CustomLocation.ServiceAccount=default" \ --configuration-settings "appsNamespace=logicapps-aca-ns" \ --configuration-settings "clusterName=<env-name>" \ --configuration-settings "keda.enabled=true" \ --configuration-settings "keda.logicAppsScaler.enabled=true" \ --configuration-settings "keda.logicAppsScaler.replicaCount=1" \ --configuration-settings "containerAppController.api.functionsServerEnabled=true" \ --configuration-settings "functionsProxyApiConfig.enabled=true" \ --configuration-settings "Azure.Cluster.Distribution=openshift" \ --configuration-settings "coreDNSVersion=1.8.6" \ --configuration-settings "envoy.serviceType=LoadBalancer" The two OpenShift-specific settings: Setting Why Azure.Cluster.Distribution=openshift Renders the chart's OpenShift branch with the privileged security contexts OpenShift requires. coreDNSVersion=1.8.6 Makes the DNS config the setup generates compatible with OpenShift's resolver so app hostnames resolve. Keep this value. Ingress setting, per your path: In-cluster LB (e.g. MetalLB) → envoy.serviceType=LoadBalancer (as above); the LB controller assigns the EXTERNAL-IP from your pool. External LB (on-prem) → envoy.serviceType=NodePort plus envoy.nodeHttpsPort=30443 and envoy.nodeHttpPort=30080, then point your external L4 LB at those NodePorts. ARO → leave envoy.serviceType=LoadBalancer; Azure assigns the EXTERNAL-IP automatically. Wait for the extension and read the ingress IP: az k8s-extension show -g <rg> --cluster-name <cluster> \ --cluster-type connectedClusters --name logicapps-aca-extension \ --query provisioningState -o tsv # -> Succeeded oc get svc microsoft-app-environment-k8se-envoy -n logicapps-aca-ns # LoadBalancer: EXTERNAL-IP | NodePort: 80:30080, 443:30443 (EXTERNAL-IP stays <none>) Step 5: Create a custom location EXT_ID=$(az k8s-extension show -g <rg> --cluster-name <cluster> \ --cluster-type connectedClusters --name logicapps-aca-extension --query id -o tsv) CC_ID=$(az connectedk8s show -g <rg> -n <cluster> --query id -o tsv) az customlocation create \ --resource-group <rg> --name <custom-location> \ --location <arc-region> --host-resource-id $CC_ID \ --namespace logicapps-aca-ns --cluster-extension-ids $EXT_ID Step 6: Create the connected environment The connected environment is the Logic Apps environment your apps live in. Whether you set --static-ip depends on your ingress: External LB + NodePort: pass --static-ip <your LB VIP>. The envoy service is a NodePort with no EXTERNAL-IP, so the platform can't discover the ingress IP on its own; you give it the LB VIP explicitly. In-cluster LB (MetalLB) or ARO: you can omit --static-ip. The platform uses the EXTERNAL-IP already assigned to the envoy LoadBalancer service. CL_ID=$(az customlocation show -g <rg> -n <custom-location> --query id -o tsv) az containerapp connected-env create \ --resource-group <rg> --name <env-name> \ --location <arc-region> --custom-location $CL_ID \ --static-ip <your-lb-vip> # external LB + NodePort; omit for in-cluster LB / ARO When you do set --static-ip, it's create-only. You can't patch it later; to change it you delete and recreate the environment. Step 7: Configure cluster DNS So that app hostnames resolve to the Envoy ingress inside the cluster, run the DNS setup with the OpenShift flag: az containerapp arc setup-core-dns --distro=openshift --verbose This creates a small coredns-custom service and adds a zone-scoped forward in OpenShift's DNS Operator that covers only the environment's domain. Every other name (internet, *.svc.cluster.local, your own domains) is left alone. Step 8: Create and deploy a Logic App You can now target the connected environment from the portal or CLI, exactly like any Logic App Standard. In the portal, choose Logic App (Standard) → Hybrid, pick your connected environment, point storage at your SMB share, and create. Once the logic app is ready, you are now ready to author and test workflows hosted in your openshift cluster. Troubleshooting common issues Symptom Cause & fix Extension install fails and rolls back with SCC/PodSecurity denials SCCs not granted before install. Grant anyuid + privileged + hostnetwork to the install namespace (Step 2), then retry. UnauthorizedNamespaceError / 401 during onboarding Custom-locations RBAC incomplete. Re-run enable-features … --custom-locations-oid <oid>; ensure the caller has Contributor/Azure Arc Kubernetes Cluster Admin. App pods stuck ContainerCreating, PVC Pending SMB driver missing/misregistered. Confirm a smb.csi.k8s.io CSIDriver exists and its pods are Running. Install one driver only. Envoy has no EXTERNAL-IP on bare metal No LoadBalancer provider. Install an in-cluster LB (MetalLB or similar) or front NodePort with an external LB (ARO does this automatically). References Setting up an OpenShift cluster Install OpenShift on bare metal Install Single-Node OpenShift (SNO) Create an Azure Red Hat OpenShift (ARO) cluster OpenShift Local (run a cluster on your laptop) Logic Apps Hybrid Set up Logic Apps Hybrid deployment
