Microsoft's Sovereign Cloud Gets a Major Upgrade: AI, Productivity, and Governance in Fully Disconnected Mode

    Hey everyone, diving into the latest from the tech world. Microsoft just dropped some exciting updates to their Sovereign Cloud offerings, and I thought it'd be worth turning this into a fresh blog post to break it down for you. If you're in enterprise IT, government, or any regulated industry, this could be a gamechanger for handling data sovereignty without sacrificing modern capabilities. Based on their official announcement, let's explore what these enhancements mean and why they matter.

Why Sovereign Clouds Are the Future of Secure Computing

In an era where data privacy regulations are tightening and cyber threats are evolving; organizations need cloud solutions that let them maintain control over their data and operations. Microsoft's Sovereign Cloud is designed exactly for allowing businesses and public sectors to operate securely, even in environments that must remain isolated from the public internet. The key? A flexible continuum of options that span connected, intermittently connected, and fully disconnected setups.

This latest update focuses on three big pillars: enhanced governance through Azure Local, boosted productivity with Microsoft 365 Local, and advanced AI support via Foundry Local. The beauty is that these tools work seamlessly together, ensuring your operations stay resilient no matter the connectivity status. Imagine running massive AI models on your own hardware, completely offline, while still enforcing strict policies. That's the promise here.

Azure Local: Running Critical Infrastructure Offline with Full Control

At the heart of these updates is Azure Local's new disconnected operations mode, now generally available. This means you can deploy and manage mission-critical workloads entirely on-premises, without needing a constant cloud connection. It's perfect for sovereign, classified, or high-risk environments where external dependencies just aren't an option.

What stands out is the consistency you get the same Azure governance and policy tools you're used to, but everything stays within your operational boundaries. Scale from small setups to large, data-heavy operations, all while maintaining unified management. As Gerard Hoffmann, CEO of Proximus Luxembourg, put it: "This model offers the resilience, autonomy and trust our market expects." It's a nod to how these features address real-world needs in places where digital sovereignty is non-negotiable.

Microsoft 365 Local: Keeping Teams Productive, No Matter What

Productivity shouldn't grind to a halt just because you're offline. Enter Microsoft 365 Local disconnected, which brings core tools like Exchange Server, SharePoint Server, and Skype for Business Server right into your sovereign private cloud. These have been battle-tested for over a decade, and now they're supported through at least 2035.

Running locally means full control over data, access, and compliance, all under your own policies. Teams can collaborate, share files, and communicate securely without ever touching the public cloud. Paired with Azure Local, it creates a cohesive stack where infrastructure and collaboration tools operate in harmony, even in total isolation.

Foundry Local: Bringing Large AI Models to Secure, Offline Environments

Perhaps the most forward-looking part is the expansion of Foundry Local, now supporting large multimodal AI models in fully disconnected setups. We're talking about integrating high-powered GPUs from partners like NVIDIA to run advanced inferencing on your hardware.

This isn't just for small-scale AI it's built for enterprise-grade models that handle complex tasks like image recognition or natural language processing, all while keeping data locked down. Microsoft provides ongoing support for deployments and updates, so you can evolve your AI capabilities without compromising security. It's a big step toward making AI accessible in the most restricted environments.

The Bigger Picture: Flexibility Without the Headaches

Microsoft's approach here is all about choice. Not every workload needs to be fully disconnected, but for those that do, these tools eliminate the trade-offs. You can standardize governance across hybrid setups, ensuring compliance and operational simplicity. Whether you're dealing with regulatory demands or just wanting bulletproof continuity, the Sovereign Private Cloud unifies everything under one roof.

Getting started is straightforward: Azure Local and Microsoft 365 Local are available worldwide now, with Foundry Local's large model support open to qualified customers. If this piques your interest, check out Microsoft's resources on Sovereign Cloud and Azure Local for more details.

Wrapping It Up: A Step Toward True Digital Independence

In summary, Microsoft's latest Sovereign Cloud enhancements are empowering organizations to embrace AI and cloud tech on their secure, compliant, and resilient. What do you think? will this shift how industries handle disconnected operations? Drop your thoughts below!

This post is inspired by Microsoft's official blog, and all credit goes to their team for the original insights.

Revolutionizing Edge Infrastructure: Public Preview of Simplified Machine Provisioning for Azure Local

 

    Hey everyone, As someone who's been diving deep into Azure Local (formally known as Azure Stack HCI), I couldn't be more excited about Microsoft's latest announcement. Deploying servers at the edge think retail stores, factories, or remote branches has always felt like a hassle. It often requires onsite IT wizards to rack, configure, and troubleshoot everything manually, which is time consuming, costly, and prone to errors, especially on a scale. But that's changing fast. On February 26, 2026, Microsoft dropped the public preview of Simplified Machine Provisioning for Azure Local, a gamechanger that lets Azure handle most of the heavy lifting remotely. Let's break it down in this blog post what it is, why it matters, how it works, and how you can get started.

What Is Simplified Machine Provisioning?

In a nutshell, this new feature shifts the complexity of setting up Azure Local hardware from onsite tinkering to centralized control in the Azure portal. No more sending skilled teams to every location; now, onsite staff just need to rack the servers, power them on, insert a prepared USB drive, and let Azure take over. It's built on the FIDO Device Onboarding (FDO) standard, which ensures secure device identity and ownership transfer right from the supply chain hello, zero trust security!

This preview is all about making edge deployments faster, more consistent, and scalable. It integrates with Azure Arc Sites, where a "site" represents a physical location like a store or factory, allowing you to manage configurations centrally and apply them across multiple machines. Once provisioned, your setup is ready for clustering and running workloads seamlessly.

Key Features That Stand Out

Microsoft packed this preview with some smart capabilities to streamline the process:

• Centralized Configuration via Azure Arc Sites: Define networking, subscriptions, and deployment settings once in the Azure portal, then reuse them for new machines. This ensures consistency across all your edge locations.
• Minimal Onsite Effort: Onsite teams handle the basic stacking, powering on, and inserting a USB prepared with Microsoft's first party tool (downloaded from the portal). After that, share the machine's ownership voucher with your IT team, and provisioning happens remotely. The USB boots into a lightweight "maintenance environment" that connects to Azure, installs extensions, and downloads the Azure Local OS.
• Automation and Visibility: Use ARM templates for automated workflows, and get real-time status updates in the Azure portal or the Configurator app. This end to end visibility helps spot issues early and speeds up troubleshooting.
• Secure and Standards Based: Leveraging FDO, it supports secure onboarding across device types, paving the way for broader edge scenarios beyond just servers.

The Benefits: Why This Matters for Your Business

If you're managing edge infrastructure, this preview could save you serious time and money. Here's how:

• Reduced Expertise Onsite: No need for deep Azure or infrastructure knowledge at remote locations, just basic hardware handling.
• Faster Deployments: Cut down setup time from days to hours by automating configurations centrally.
• Scalability and Consistency: Easily roll out to multiple sites without variability, thanks to site-based configs and automation.
• Better Security and Monitoring: Built in zero trust features and deployment tracking mean fewer risks and quicker resolutions.

This means less travel for IT teams and more focus on business growth.

How It Works: A Step by Step Overview

At a high level, the process is straightforward and divided into onsite and remote steps. For the nitty-gritty, check out Microsoft's detailed guide.

Onsite Setup

1. Prepare a USB drive on a Windows 11 PC using the USB Preparation Tool (download from Azure portal along with the maintenance environment ISO). This erases the drive and makes it bootable.
2. Insert the USB into each server, power on, and boot from it (tweak BIOS if needed enable Secure Boot and TPM). Wait about 30 minutes for setup; the machine reboots a couple of times.
3. Collect the ownership voucher using the Configurator app (connect via machine serial number or IP) or from the USB itself. Share it with your IT team.

Remote Provisioning in Azure

1. Create an Azure Arc site in the portal and configure site level settings like time zone and NTP server.
2. Upload vouchers, set software version, local admin credentials, and machine names.
3. Review and create; monitor progress in the portal until the status shows "Ready to cluster." The machines auto connect to Azure for OS installation and Arc setup.

Post Provisioning

Once done, use existing Azure Arc flows to create clusters and deploy workloads.

Prerequisites to Note: You'll need validated hardware (like Lenovo, HPE, or Dell SKUs), Azure subscriptions with specific resource providers registered, and roles like Owner/Contributor. During preview, it's limited to East US region, and features like Azure Arc gateway aren't supported yet.

Troubleshooting: Keep machines powered and networked; use the Configurator app for Realtime monitoring.

Wrapping Up: Time to Dive In!

This public preview is a big step toward making edge computing as easy as cloud native setups. If you're tired of clunky onsite configs (like those Azure Stack HCI networking headaches we've chatted about), this could be your solution. Head over to aka.ms/provision/tryit to get started, or check the docs at aka.ms/provision/doc for more. Microsoft wants your feedback to shape the future let’s make edge deployments effortless!

What do you think? Drop a comment below if you're trying this out. Stay tuned for more Azure insights! 🚀

 

Enhancing Resilience with Azure Local Rack Aware Clustering: A Deep Dive into High-Availability On-Premises

    In the evolving world of hybrid cloud, Microsoft continues to bridge the gap between Azure's cloud-native capabilities and on-premises infrastructure. One of the standout recent additions is rack aware clustering in Azure Local (formerly building on Azure Stack HCI concepts). Currently available in preview (as of Azure Local 2510 and later), this feature lets you build highly resilient clusters that span physical racks—treating each as a local availability zone—without sacrificing the seamless Azure management experience.

What Is Rack Aware Clustering in Azure Local?

At its core, rack aware clustering distributes your Azure Local nodes across two physical racks (typically in separate rooms or buildings within the same site), connected via high-bandwidth, low-latency links using top-of-rack (ToR) switches.

Each rack operates as a local availability zone, extending awareness from the operating system layer all the way up to Azure Local management and Azure Arc-enabled VMs. This setup supports a single unified storage pool (powered by Storage Spaces Direct), with data replicas (mirrors) distributed evenly across both racks. If one rack goes down—due to power failure, fire, or hardware issues—the surviving rack maintains access to data and workloads, enabling automatic failover without data loss.

A key diagram from Microsoft illustrates this beautifully: two racks of servers linked by ToR switches between rooms, forming a fault-tolerant cluster with synchronous replication over a dedicated storage network.

Key Benefits

Rack aware clustering shines in scenarios demanding extreme uptime and rack-level fault tolerance:

• High Availability: Survive the complete loss of a rack while keeping applications running—no more single points of failure at the physical rack level.
• Even Data Distribution: Storage Spaces Direct ensures replicas are balanced across zones, reducing risk during failures and improving failover smoothness.
• Better Load Balancing & Performance: Distribute workloads (VMs, AKS clusters) across zones for optimized resource use and lower latency within the site.
• Azure-Native Management: Full integration with Azure Arc means you manage VMs, Kubernetes, monitoring, and more through the familiar Azure portal—consistent across hybrid environments.

This is especially valuable in regulated or mission-critical environments like manufacturing plants, hospitals, airports, or campuses where a single rack failure could disrupt operations.

Supported Configurations & Requirements

Rack aware clusters are designed for balanced, symmetric setups:

• Start with a 2+2 configuration (2 nodes per rack = 4 total) and scale to 3+3 (6 nodes) or 4+4 (8 nodes) by adding matched node pairs.
• Storage Resiliency: Uses two-way mirrors (for 2+2) or four-way mirrors (for larger), with storage efficiency at 50% or 25% respectively. Only all-flash NVMe/SSD data drives are supported—no external SANs.
• Networking Essentials: Round-trip latency between racks ≤ 1 ms (critical for synchronous RDMA-based replication). A dedicated storage network intent is required, with bandwidth scaling by cluster size (e.g., 40–200 GbE depending on NIC speed and node count).
• Witness: Typically uses a cloud witness (default), with options for local if needed.
• Deployment: Only for new Azure Local instances (no conversion from standard clusters). Deploy via the Azure portal or ARM templates. Post-deployment, verify machines are grouped by zone and test VM failover/live migration.

Unsupported in this release: External SANs, 3-way mirrors, adding nodes to 1+1 configs, or certain affinity rules via legacy tools.

For detailed network designs (options A–D with ToR redundancy, VLAN isolation, SDN support), check the reference architecture docs.

Use Cases & Real-World Value

Imagine a factory floor where regulatory compliance demands physical separation of critical systems—rack aware clustering delivers zone-like isolation without stretching across distant sites. Or in a hospital campus: place racks in different buildings to guard against localized disasters while keeping everything under one Azure-managed cluster.

It also pairs nicely with Azure Arc-enabled services: provision VMs into specific zones (strict or non-strict placement) for performance tuning, redundancy, or compliance, and run AKS clusters with nodes spread for better fault tolerance.

Wrapping Up: Is Rack Aware Clustering Right for You?

If you're running (or planning) Azure Local for edge, industrial, or on-premises workloads and need more than basic node-level HA, rack aware clustering is a game-changer. It evolves the old "stretched cluster" concepts into a more modern, Azure-integrated solution focused on local resilience.

The feature is in preview now, with a smooth upgrade path to GA expected in 2026—no redeployment required. If you're interested, start by reviewing the full overview on Microsoft Learn:

• Overview of Azure Local rack aware clustering
• Requirements & Supported Configurations
• Reference Architecture

Have you deployed Azure Local yet? Planning to try rack aware mode? Drop a comment—I'd love to hear your thoughts or experiences!

#Azure #AzureLocal #AzureArc #HighAvailability #OnPremisesCloud

Preparing Active Directory for Azure Local Deployment: A Step-by-Step Guide

 In the realm of hybrid cloud solutions, Azure Local brings the power of Azure to your on-premises environment. But before you dive into deployment, ensuring your Active Directory (AD) is properly configured is crucial. This setup optimizes performance, enhances security, and prevents common pitfalls like configuration drifts or permission issues. Drawing from Microsoft's official guidance, this blog post walks you through the essentials of prepping AD for Azure Local (version 23H2 and later). We'll cover prerequisites, key configurations, a detailed how-to, and tips to avoid headaches.

Overview: Why Prep Active Directory?

Active Directory serves as the backbone for authentication and management in Azure Local clusters. Proper preparation ensures seamless integration, from creating dedicated organizational units (OUs) to handling DNS and permissions. Without this, you might face slow queries in large directories, security vulnerabilities, or deployment failures. The goal is to create a controlled environment where Azure Local can manage its own security defaults while respecting your AD structure.

Key elements include scoping permissions to a dedicated OU, blocking Group Policy Object (GPO) inheritance to prevent conflicts, and managing DNS for reliable name resolution—especially in disjoint namespace scenarios.

Prerequisites: What You Need Before Starting

Before configuring AD, gather these essentials:

• Dedicated OU: Create one specifically for Azure Local computer objects and the cluster Computer Name Object (CNO). This isolates and speeds up queries in multi-site AD environments.
• Deployment User: A user account with permissions limited to the OU. It can be anywhere in the directory but must handle computer object creation/deletion and BitLocker recovery info.
• DNS Server: Preferably Microsoft DNS integrated with AD for secure dynamic updates. If using non-Microsoft DNS, prepare to manually create records.
• PowerShell Access: You'll need the Active Directory module for scripting permissions.
• Optional Precreations: Computer accounts and cluster CNO can be precreated using the deployment user.

Benefits of Proper AD Preparation

Getting AD ready isn't just a checkbox—it's a foundation for success:

• Enhanced Security: Scoped permissions minimize risks by limiting access to only what's needed.
• Performance Optimization: A dedicated OU reduces query times in large AD setups.
• Conflict Prevention: Blocking GPO inheritance lets Azure Local enforce its drift-protected security defaults without interference.
• Reliable Operations: Proper DNS handling ensures smooth cluster aware updating (CAU) and avoids manual interventions.

In short, this prep work saves time during deployment and reduces post-setup troubleshooting.

Step-by-Step Guide: Configuring Active Directory

Follow these steps to set up AD for Azure Local. Use PowerShell for precision, especially with permissions.

1. Create the Dedicated OU and Deployment User

• Run PowerShell commands like New-ADOrganizationalUnit to create the OU (e.g., "HCI001").
• Create the deployment user with New-ADUser.

2. Assign Permissions to the Deployment User

• Import the AD module: Import-Module ActiveDirectory.
• Define variables for OU path (e.g., $OUpath = 'OU=HCI001,DC=contoso,DC=com') and user (e.g., $User = 'deploymentuser').
• Get the user's SID and OU ACL.
• Create and apply access rules:
  text

  $createChild = New-Object System.Security.AccessControl.AccessRule($sid, "CreateChild, DeleteChild", "Allow", $computerObjectGuid, "All", $guidNull)
  $readProperty = New-Object System.Security.AccessControl.AccessRule($sid, "ReadProperty", "Allow", $guidNull, "Descendents", $guidNull)
  $fullControlBitLocker = New-Object System.Security.AccessControl.AccessRule($sid, "GenericAll", "Allow", $guidNull, "Descendents", $bitLockerObjectGuid)
  $acl.AddAccessRule($createChild)
  $acl.AddAccessRule($readProperty)
  $acl.AddAccessRule($fullControlBitLocker)
  Set-Acl -Path "AD:\$OUpath" -AclObject $acl
  This grants create/delete on computers, read on all, and full control on BitLocker recovery objects.Note: Don't use the AD delegation wizard for BitLocker permissions—stick to PowerShell.

3. Block Group Policy Inheritance

• Use: Set-GPInheritance -Target $OUpath -IsBlocked Yes.
• This prevents external GPOs from overriding Azure Local's settings.

4. Handle Disjoint Namespace (If Applicable)

• Append the AD domain DNS suffix to management adapters: Set-DnsClient -InterfaceIndex <index> -ConnectionSpecificSuffix "contoso.com".
• Verify: nslookup hostname.contoso.com.
• Avoid GPO-based DNS suffix lists—they're not supported.

5. Configure DNS and Disable Dynamic Updates for CAU

• Disable dynamic DNS: Get-NetAdapter "vManagement*" | Set-DnsClient -RegisterThisConnectionsAddress $false.
• If no secure dynamic updates, manually create Host A records for machine names, CNO, and VCO.
• Prestage the VCO per Microsoft's failover clustering guide.

6. Verify Configurations

• Check DNS records: nslookup "<machine name>".
• Ensure everything resolves to FQDNs.

Best Practices and Troubleshooting

• Security Best Practices: Always scope permissions to the OU. Use secure dynamic updates where possible to automate DNS.
• Warnings: Precreate objects if needed, but do it with the deployment user. Create DNS records right after disabling updates to avoid drifts.
• Troubleshooting: If queries are slow, confirm the dedicated OU. For DNS issues, double-check suffixes and records. If drifts occur, verify dynamic updates are off—Azure Local will rollback changes.

Conclusion

Prepping Active Directory for Azure Local is a straightforward process that pays off in stability and efficiency. By following these steps, you'll set up a secure, optimized environment ready for deployment. Remember, this is tailored for version 23H2—always check Microsoft's docs for updates. If you run into snags, tools like nslookup and PowerShell diagnostics are your friends. Happy deploying!

Simplifying Networking in Azure Local: A Deep Dive into Network ATC

    In the world of hybrid cloud infrastructure, managing networks in clustered environments like Azure Local can be a daunting task. Enter Network ATC—a powerful tool that's revolutionizing how administrators deploy and maintain host networking. Whether you're dealing with Azure Local or its Azure Local variant, Network ATC brings intent-based automation to the forefront, ensuring consistency, reducing errors, and enforcing best practices. In this blog post, we'll explore what Network ATC is, its core features, benefits, deployment steps, and some practical tips to get you started.

What is Network ATC?

Network ATC stands for a streamlined approach to networking configuration in Azure Local and Azure Local clusters. It's not just an acronym—it's a full-fledged tool that automates the deployment and operation of host networks using "intents." These intents define how physical network adapters should be used, specifying types like management, compute, storage, or even stretch for distributed setups.

At its core, Network ATC shifts from manual, error-prone configurations to an intent-based model. You declare your networking goals (e.g., "Use these adapters for storage traffic with specific VLANs"), and the system handles the rest: creating virtual switches, assigning IPs, setting VLANs, and more. This ensures symmetry across all cluster nodes, where adapters are configured identically based on make, model, and speed. It's mandatory in Azure Local 23H2 and later, and it's deeply integrated with tools like Windows Admin Center and PowerShell for ease of use.

In Azure Local contexts, Network ATC extends this to scenarios like stretched Storage Spaces Direct (S2D) clusters, where it handles storage replica networks without RDMA support, though you'll need to manually assign IPs in those cases.

Key Features of Network ATC

Network ATC packs a punch with features designed to make your life easier:

• Intent-Based Configuration: Define intents with a name, adapters, and types (Management, Compute, Storage, Stretch). Adapters can only belong to one intent, but you can have multiple intents per cluster. For example, a single intent might group management and compute traffic on shared adapters via an Embedded Switch Team (SET).
• Overrides for Customization: Not everything fits the defaults. Use overrides for adapters (e.g., RDMA, MTU like JumboPacket=9014), storage (e.g., disable auto IP generation), QoS, cluster settings, and proxies. This allows fine-tuning without breaking the automation.
• Automation and Validation: It automatically configures Data Center Bridging, virtual adapters, VLANs, and even cluster network naming (e.g., "storage_compute_VLAN711"). Plus, it regularly validates setups and remediates drifts—like reverting unauthorized MTU changes.
• Live Migration Optimization: Manages settings for maximum migrations, networks, and SMBDirect (RDMA) bandwidth, with overrides available.
• Proxy and Stretch Support: Ensures consistent proxy configs across nodes and supports stretched S2D without assigning IPs automatically.
• Networking Patterns: Choose from predefined patterns like grouping all traffic, management/compute together, or compute/storage, to guide your intents.

Starting from Azure Local 22H2, it even auto-detects cluster scopes and verifies adapter symmetry.

Benefits: Why Bother with Network ATC?

Adopting Network ATC isn't just about following trends—it's about real-world gains:

• Reduced Complexity and Time: Say goodbye to manual setups that take hours. Intents automate everything, cutting deployment time dramatically.
• Error Reduction and Consistency: Enforces Microsoft-validated best practices, ensuring no configuration drift. All nodes stay in sync, preventing mismatches that could cause outages.
• Built-in Remediation: If someone tweaks an MTU outside the intent, Network ATC spots it and fixes it automatically.
• Scalability for Hybrid Setups: Perfect for Azure Local's hybrid nature, with seamless integration for cloud deployments that auto-create intents based on patterns.

Compared to pre-Network ATC methods, which were manual and prone to inconsistencies, this is a game-changer—especially in versions 21H2 onward, maturing through 22H2 and becoming essential in 23H2+.

How to Deploy Network ATC: A Step-by-Step Guide

Ready to implement? Here's a practical guide based on proven steps.

Prerequisites

• Run on Windows Server Datacenter with Failover Clustering enabled.
• Install features on all nodes:
  text

  Install-WindowsFeature -Name NetworkATC, NetworkHUD, Hyper-V, 'Failover-Clustering', 'Data-Center-Bridging' -IncludeManagementTools
• Ensure adapters are in the same PCI slots across nodes for consistency.

Creating Intents

Use PowerShell to add intents. For a management/compute setup:

text

$adapteroverrides = New-NetIntentAdapterPropertyOverrides
$adapteroverrides.NetworkDirect = $false
$adapteroverrides.JumboPacket = "9014"
Add-NetIntent -Name Management_Compute -Management -Compute -AdapterName pMGMT01, pMGMT02 -ManagementVlan 31 -AdapterPropertyOverrides $adapteroverrides

For storage:

text

$storageoverrides = New-NetIntentStorageOverrides
$storageoverrides.EnableAutomaticIPGeneration = $false
$adapteroverridesstorage = New-NetIntentAdapterPropertyOverrides
$adapteroverridesstorage.JumboPacket = "9014"
Add-NetIntent -Name Storage -Storage -AdapterName pSMB01, pSMB02 -StorageVlans 711,712 -StorageOverrides $storageoverrides -AdapterPropertyOverrides $adapteroverridesstorage

Monitoring and Validation

Check status:

text

Get-NetIntentStatus | sort host | ft Intentname,host,ConfigurationStatus,ProvisioningStatus

For SDN clusters, remove existing VMSwitches first:

text

Get-VMSwitch -Name | Remove-VMSwitch -force
``` But note challenges with running VMs.

## Best Practices and Troubleshooting

- **Consistency is Key**: Always match adapter placements and test in labs.
- **SDN Integration**: Wait for Arc-enabled SDN GA if using SDN.
- **Limitations to Watch**: No RDMA for stretch intents; manual IPs for stretched S2D; can't change SR-IOV post-switch creation.
- **Troubleshooting**: If a VMSwitch is deleted, Network ATC should recreate it, but monitor management IPs—they might fallback temporarily.

## Conclusion

Network ATC is a must-have for anyone managing Azure Local or Azure Local clusters. By automating configurations and enforcing standards, it frees you from networking headaches, letting you focus on what matters. If you're on 23H2 or later, it's not optional—it's essential. Dive in with the steps above, and you'll see the difference in no time. Happy networking!

Running Azure Local in Disconnected Mode: A Game-Changer for Edge Computing

    Imagine running Azure services in a remote oil rig, a secure government facility, or a manufacturing site with no reliable internet connection. Sounds challenging, right? With Azure Local's Disconnected Operations (Preview), Microsoft is making it possible to bring the power of Azure to environments where cloud connectivity isn’t an option. In this blog post, we’ll dive into what disconnected operations for Azure Local is, why it matters, and how it can transform the way organizations manage workloads in isolated or secure environments. Let’s explore!

What Are Disconnected Operations for Azure Local?Azure Local, powered by Azure Arc, is a distributed infrastructure solution that lets you run virtual machines (VMs), containers, and select Azure services on-premises or at the edge. The Disconnected Operations feature takes this a step further by enabling the deployment and management of Azure Local instances without a connection to the Azure public cloud. This means you can build, deploy, and manage VMs and containerized applications using a local control plane, all while maintaining a familiar Azure portal and CLI experience.This feature, currently in preview, is designed for scenarios where connectivity is limited, security is paramount, or data sovereignty is a must. It’s like having a mini Azure data center right where you need it—no internet required!Why Use Disconnected Operations?Disconnected operations open up a world of possibilities for industries and scenarios where staying offline is critical. Here are some key use cases:

• Data Sovereignty and Compliance: Sectors like government, healthcare, and finance often face strict regulations requiring data to stay within organizational or geographic boundaries. Disconnected operations ensure that both data and control remain local, helping meet compliance requirements.
• Remote or Isolated Locations: Think oil rigs, mining operations, or remote research stations. These locations often lack stable internet access. With disconnected operations, you can still leverage Azure Arc-enabled services to run workloads seamlessly.
• Enhanced Security: For industries with stringent security needs, operating offline reduces the attack surface by eliminating exposure to external networks. It’s a critical advantage for high-security environments like defense or critical infrastructure.

Whether it’s keeping sensitive data on-site or powering mission-critical applications in remote areas, disconnected operations make Azure Local a versatile solution for edge computing.Supported Services in Disconnected ModeDisconnected operations for Azure Local support a robust set of services, ensuring you can manage your infrastructure and workloads effectively. Here’s what’s included:

• Azure Portal: Enjoy a familiar Azure portal experience tailored for disconnected environments.
• Azure Resource Manager (ARM): Manage subscriptions, resource groups, ARM templates, and use the Azure CLI.
• Role-Based Access Control (RBAC): Implement fine-grained access control for subscriptions and resource groups.
• Managed Identity: Use system-assigned managed identities for supported resource types.
• Arc-enabled Servers and VMs: Manage VM guests and set up Windows or Linux VMs on Azure Local.
• Arc-enabled Kubernetes: Connect and manage Kubernetes clusters for unified configuration.
• Azure Kubernetes Service (AKS): Deploy and manage AKS clusters on Azure Local.
• Container Registry: Store and retrieve container images and artifacts.
• Key Vault: Securely store and access secrets.
• Policy Enforcement: Enforce compliance standards when creating new resources.

These services allow you to maintain a consistent Azure experience, even in fully disconnected environments.Prerequisites for Disconnected OperationsBefore diving into disconnected operations, you’ll need to ensure your setup meets specific requirements. Here’s a quick checklist:Hardware RequirementsDisconnected operations require a virtual appliance that runs on Azure Local instances, which means planning for extra capacity. Each node in your cluster needs:

• Minimum 3 nodes for redundancy.
• 64 GB memory per node.
• 24 physical cores per node.
• 2 TB SSD/NVMe storage per node (plus a 480 GB SSD/NVMe boot drive).
• Network: Supports both switchless (for three-node clusters) and switched configurations.

You’ll also need to account for additional capacity for VM or AKS workloads, so plan your hardware accordingly.Integration RequirementsTo deploy disconnected operations, integrate with existing datacenter assets:

• Identity: Use Active Directory Federation Service (ADFS) on Windows Server 2022 for authentication and LDAP for group membership synchronization.
• Public Key Infrastructure (PKI): Support for private or public PKIs, with Active Directory Certificate Services (ADCS) validated as a private PKI solution.
• Network Time Protocol (NTP): Optional local or public time server for system clock synchronization.
• Domain Name System (DNS): Required for resolving Azure Local endpoints and configuring ingress IPs.

Access RequirementsEnsure you have permissions to:

• Create service accounts with read access for LDAP integration.
• Manage DNS records or zones.
• Create and export certificates for secure endpoints.
• Configure firewall settings if a local firewall is in place.

Preview ParticipationSince this feature is in preview, you’ll need:

• An enterprise agreement with Microsoft (typically three years).
• A valid business need for disconnected operations (e.g., regulatory or connectivity constraints).
• Validated Azure Local hardware from the Azure Local catalog.

To join the preview, submit a form and await approval, which typically takes up to 10 business days. If approved, you’ll receive instructions to acquire and deploy the feature.Getting Started with Disconnected OperationsReady to bring Azure Local to your disconnected environment? Here’s how to get started:

1. Verify Prerequisites: Ensure your hardware, integration, and access requirements are met.
2. Submit for Preview Access: Complete the preview participation form and wait for Microsoft’s approval.
3. Deploy the Virtual Appliance: Use the provided instructions to set up the disconnected operations virtual appliance on your Azure Local instance.
4. Configure Services: Leverage the Azure portal or CLI to manage VMs, Kubernetes clusters, and other supported services.
5. Monitor and Manage: Use Azure Policy and other tools to enforce compliance and manage resources at scale.

For detailed deployment steps, check out Microsoft’s guide on Deploy Disconnected Operations for Azure Local (Preview).Why This Matters for the Future of Edge ComputingDisconnected operations for Azure Local are a game-changer for organizations operating in challenging environments. By bringing Azure’s powerful management tools and services to disconnected scenarios, Microsoft is empowering industries to innovate without compromising on security, compliance, or connectivity limitations. Whether you’re in a remote location or a highly regulated industry, this feature ensures you can harness the full potential of Azure Arc-enabled services anywhere.As this feature is still in preview, now’s the perfect time to explore its capabilities and provide feedback to shape its future. If you’re ready to take your edge computing strategy to the next level, Azure Local’s disconnected operations could be the key to unlocking new possibilities.

---

Ready to try it out? Visit the Azure Local documentation to learn more and start your journey with disconnected operations. Let us know in the comments how you’re using Azure Local in your organization and if you are looking for subject matter experts to help you along the way contact us at Acuutech: Acuutech | Cloud Solutions