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
Dynamic Mandatory Fields
In a SharePoint library, I have folders which are = a. Admin b. Events c. Furniture and Moves d. Janitorial and Maintenance e. Parking and Transportation f. Shipping and Receiving g. Supplies and Equipment h. Waste and Recycling I have Meta data across the library whose data type are all choices and are: a. Document Type = Contract, Financial, planning b. Building = Gym, Garage, Heating c. Asset Category = Office, Playground d. Fiscal Year = FY23, FY24, FY25, FY26, FY27 e. Vendor = Maple Leaf, Canadian Tire, Home Depot f. Status = Active, Pending, Not Active g. Retention Label = 3 years, 5 years h. Service Type = Admin, Events, Furniture and Moves, Janitorial and Maintenance, Parking and Transportation, Shipping and Receiving, Supplies and Equipment, Waste and Recycling Service Type and Retention Label are mandatory fields, with the Rule below for all the files in the various folders: IF Folder Name = Admin, then Service Type = Admin and Retention Label = 5 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Events, then Service Type = Events and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year, Building and Vendor IF Folder Name = Furniture and Moves, then Service Type = Furniture and Moves and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Building IF Folder Name = Janitorial and Maintenance, then Service Type = Janitorial and Maintenance and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Parking and Transportation, then Service Type = Parking and Transportation and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Shipping and Receiving, then Service Type = Shipping and Receiving and Retention Label = 3 years; the mandatory fields should be Document Type, Status IF Folder Name = Supplies and Equipment, then Service Type = Supplies and Equipment and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Waste and Recycling, then Service Type = Waste and Recycling and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Vendor I have used Column Default Value Settings for SharePoint to display Auto-Display the Service Type and Retention Label, but I cannot seem to perform the conditional mandatory fields using Validations setting for the other requirements. Please helpPlanning the Monitoring of my hybrid environment.
Hello folks, By now you may have read that I’ve rebuilt my demo environment to look like what a typical hybrid environment would look like. I did it slowly without having to rip and replace everything in my on-prem environment. Started out with establishing a site-to-site VPN, then a solution to remote into all the servers in my environment, configured a resilient way of resolving the names of all servers in my hybrid deployment, and lastly, configuring an Azure Arc Private Link Scope so that all my on-prem machines could connect to Azure using the VPN and not the open internet. Now as I look at all the operational tasks I need to implement (monitoring/insights, patch management, change management, etc...) To support all these operational requirements, I need the common underpinning provided by the Azure Log Analytics workspace.Recycle Bin and Site Content Hidden for Site Members and Site Visitors
I posted this before but made a mistake with my write up, so I am reposting. I have a requirement that the Recycle bin and Site Contents should be be hidden from the Site Members and Site Visitors. Please how can I achieve this because the Server Infrastructure activation is not working for me. Any workarounds? Please helpHVE for Microsoft 365: When to Use It, When Not To, and Who Should Be Allowed to Send at Scale
Microsoft recently announced the General Availability of High Volume Email for Microsoft 365, also known as HVE, in Exchange Online. This is an important and long-awaited capability for organizations that need to send large volumes of internal email from applications, devices, or line-of-business systems without using regular user mailboxes as bulk-sending engines. But HVE should not be misunderstood. It does not mean that every mailbox in Exchange Online should now be used for mass email. It does not mean Exchange Online has become a general-purpose marketing platform. And it does not remove the need for proper outbound email governance. Why HVE Matters For years, many organizations have used regular Exchange Online mailboxes, shared mailboxes, or service accounts to send automated messages from applications, scanners, monitoring platforms, ticketing platforms, and custom business applications. That approach creates several problems. Standard mailboxes are designed for human and business communication, not for sustained high-volume automated traffic. Exchange Online has recipient limits, message rate limits, outbound spam protections, and tenant-level controls to protect the service and reduce abuse. HVE introduces a more appropriate model for specific high-volume scenarios. Instead of using a normal mailbox for automated traffic, organizations can create dedicated HVE accounts and use specific SMTP endpoints, admin controls, reporting, and governance for approved high-volume internal messaging scenarios. What HVE Is Designed For HVE is designed for automated, operational, and transactional messaging at scale, primarily for internal recipients within the tenant. Examples include: Internal application notifications. Line-of-business system messages. Device-generated messages. Operational alerts. Security advisories. Internal workflow communications. Monitoring platform alerts. IT service notifications. Large-scale internal announcements generated by systems. This is especially relevant when the organization needs to send messages at scale but still wants to keep the workload within Microsoft 365 governance and Exchange Online mail flow. In practical terms, HVE is useful when the sender is not a human user, but a controlled business system. What HVE Is Not HVE is not a replacement for marketing platforms. HVE is not a general-purpose internet bulk email engine. HVE is not a way to bypass Exchange Online sending limits for external campaigns. HVE is not the correct platform for newsletters, promotional campaigns, large-scale customer communication, or high-volume external transactional email. For external transactional, marketing, or customer-facing bulk email, organizations should evaluate platforms designed for that purpose, such as Azure Communication Services Email, SendGrid, Amazon SES, Mailchimp, Brevo, or another specialized delivery platform. When to Use HVE Use HVE when the workload matches these characteristics: The sender is an application, device, service, or business system. The recipients are primarily internal users in the Microsoft 365 tenant. The volume is higher than what should be sent from a standard mailbox. The workload is operational, automated, or transactional. The organization needs centralized Microsoft 365 administration and reporting. The organization wants to avoid impacting user mailbox sending limits. The use case is approved, documented, monitored, and governed. Good examples: A security platform sending internal security advisories. A monitoring system sending infrastructure alerts to internal teams. A business workflow system sending high-volume approval or status notifications. An IT service platform sending internal notifications. A service management platform sending ticket updates to internal users. A device management system sending operational messages to internal teams. When Not to Use HVE Do not use HVE when the workload is external bulk email. Avoid HVE for: Marketing campaigns. Newsletters to customers. Promotional email. Mass external invitations. External transactional email at scale. Customer invoices and receipts in high volume. OTP or password reset flows for external users. External portal notifications. Any workload where deliverability, bounce handling, reputation management, unsubscribe handling, analytics, or customer consent management are required. Those workloads require a platform designed for external delivery, reputation management, suppression lists, opt-out, tracking, bounce handling, and compliance. Who Should Be Allowed to Use HVE HVE should not be enabled casually for every team or every application. It should be treated as a controlled platform capability. Recommended eligible senders: Approved line-of-business applications. Corporate systems owned by IT, Security, Operations, Facilities, or Service Management teams. Managed devices or services with a clear business purpose. Internal platforms that send operational messages to employees. Applications with documented ownership, authentication, monitoring, and expected volume. Recommended non-eligible senders: Normal users. Shared mailboxes used by humans. Marketing teams sending to external audiences. Unmanaged scripts. Legacy systems with no owner. Applications with unknown volume. Systems that send to external recipients at scale. Any application using HVE just to avoid standard mailbox limits. The core principle is simple: HVE should be enabled for workloads, not for convenience. Governance Model Before enabling HVE, organizations should define a governance model. At minimum, each HVE account should have: A named business owner. A technical owner. A documented purpose. Expected daily and monthly volume. Recipient scope. Authentication method. Monitoring process. Incident response path. Decommissioning criteria. Review frequency. HVE accounts should not become invisible service accounts that nobody owns. They should be treated as privileged communication identities. Security and Authentication HVE supports OAuth authentication, and Microsoft provides guidance for restricting OAuth authentication to specific Microsoft Entra ID applications. This is important because organizations should avoid broad, uncontrolled access. They should restrict which applications can send through each HVE account, monitor usage, and separate workloads by purpose. For example: One HVE account for security alerts. One HVE account for monitoring systems. One HVE account for IT service notifications. One HVE account for internal operational communications. This separation improves visibility, investigation, accountability, and risk containment. HVE vs Standard Exchange Online Mailboxes A standard Exchange Online mailbox should be used for normal human communication. A shared mailbox should be used for collaborative business processes. An HVE account should be used for approved high-volume internal system email. A dedicated external delivery platform should be used for marketing, bulk external communication, or high-volume transactional email. Scenario Recommended Platform Human business email Exchange Online mailbox Team or department mailbox Shared mailbox Low-volume application notifications Standard Exchange Online, if approved High-volume internal system notifications HVE Internal operational alerts at scale HVE Marketing campaigns Marketing platform External transactional email Transactional email service Customer newsletters Marketing automation platform OTP/password reset for external users Dedicated transactional platform External bulk email Dedicated bulk email provider HVE and the Mailbox External Recipient Rate Limit Cancellation Microsoft also announced that the Mailbox External Recipient Rate Limit in Exchange Online was cancelled indefinitely. However, that cancellation should not be interpreted as permission to use Exchange Online for uncontrolled bulk sending. Microsoft was clear that other limits remain unchanged, including the existing Recipient Rate Limit and the Tenant-level External Recipient Rate Limit. That distinction is important. The cancellation of one mailbox-level external recipient limit does not remove the need for proper architecture. Exchange Online still has service limits. Outbound spam controls still apply. Tenant-level protections still matter. And HVE is still not a marketing engine. Practical Architecture Decision Before enabling HVE, ask these questions: Who is sending? Is the sender a human, shared mailbox, application, or device? Who are the recipients? Are they internal or external? What is the expected volume? Is the workload operational, transactional, promotional, or human communication? Does the business need Microsoft 365 mail flow and governance? Does the use case require bounce handling, unsubscribe, tracking, or reputation management? Is the application properly authenticated and monitored? Who owns the account? Who approves the sending pattern? Who responds if the account is abused? If the workload is internal, automated, high-volume, and business-approved, HVE may be the right answer. If the workload is external, promotional, customer-facing, or marketing-driven, use a dedicated email delivery platform. Recommended Enablement Approach Organizations should enable HVE in phases. First, identify existing systems currently using user mailboxes, shared mailboxes, or SMTP AUTH for automated sending. Second, classify each workload as internal, external, operational, transactional, marketing, or human communication. Third, migrate only approved internal high-volume workloads to HVE. Fourth, move external high-volume workloads to dedicated email delivery platforms. Fifth, monitor usage and review HVE accounts regularly. This avoids turning HVE into another uncontrolled sending layer. Conclusion High Volume Email for Microsoft 365 is an important addition to Exchange Online. It gives organizations a native way to support high-volume internal system messaging without using standard mailboxes for automated high-volume traffic. But HVE is not a free pass for bulk email. It is not a marketing platform. It is not a replacement for transactional email services. And it should not be enabled for every mailbox or every application. The right approach is workload classification. Use Exchange Online for corporate communication. Use HVE for approved high-volume internal system messaging. Use dedicated platforms for external bulk, marketing, and transactional email. The question is not only: “Can this system send email through Microsoft 365?” The better architectural question is: “What type of email is this, who is the audience, and what is the correct platform for this workload?” That is where proper email architecture begins.
