Automating Azure Local SDN with PowerShell, WAC, and Bicep: Step‑by‑Step Guide

TL;DR

• Define infrastructure prerequisites and link to Microsoft’s documentation
• Automate SDN deployments with WAC, PowerShell, and Bicep
• Reuse ready-made scripts and templates
• Integrate automation into DevOps pipelines
• Understand common pitfalls and SDN operational best practices

---

Introduction

Azure Local SDN (formerly Azure Stack HCI SDN) introduces software-defined networking to on-premises infrastructure. As enterprises seek agility and consistent governance across hybrid environments, automating the configuration and management of SDN becomes essential. Using PowerShell, Windows Admin Center (WAC), and Bicep together allows infrastructure teams to move away from manual provisioning and toward scalable, repeatable, and compliant operations.

---

Prerequisites

Before beginning, ensure the following prerequisites are in place:

Infrastructure

• Azure Local host cluster with SDN feature enabled
• Physical network that supports VLAN, BGP, LLDP
• Active Directory domain joined nodes
• Correct time synchronization and DNS resolution across all nodes

Tools & Modules

• Windows Admin Center with the SDN Infrastructure extension installed
• PowerShell with latest Az.Network module
• Bicep CLI (latest release)

Official Documentation

Refer to Microsoft’s up-to-date requirements here:
Microsoft Azure Local SDN Prerequisites

---

Step 1: Automating via Windows Admin Center

Windows Admin Center provides a graphical wizard to automate core SDN components such as the Network Controller, Software Load Balancer (SLB), and Gateway virtual appliances.

Steps:

1. Open WAC and connect to your Azure Local cluster.
2. Go to SDN Infrastructure and launch the wizard.
3. Provide the necessary host, network, and storage configurations.
4. Validate settings and complete the deployment.

Although WAC simplifies the process, its automation is limited to initial deployment. For full repeatability and portability, combine it with scripting (PowerShell and Bicep).

---

Step 2: PowerShell Automation

Use PowerShell for programmatic control over SDN resources.

Example: Create SDN Virtual Network & Subnet

Connect-AzAccount
$rg = "SDN-ResourceGroup"

$vnet = New-AzVirtualNetwork -Name "SDN-VNet" -ResourceGroupName $rg `
  -Location "centralus" -AddressPrefix "10.10.0.0/16"

Add-AzVirtualNetworkSubnetConfig -Name "TenantSubnet" `
  -AddressPrefix "10.10.1.0/24" -VirtualNetwork $vnet

$vnet | Set-AzVirtualNetwork

Example: Create NSG with ACL Rules

$nsg = New-AzNetworkSecurityGroup -Name "TenantNSG" `
  -ResourceGroupName $rg -Location "centralus"

Add-AzNetworkSecurityRuleConfig -Name "AllowInternal" `
  -NetworkSecurityGroup $nsg -Direction Inbound `
  -Priority 200 -Access Allow -Protocol * `
  -SourceAddressPrefix "10.10.1.0/24" `
  -DestinationAddressPrefix "10.10.1.0/24" `
  -SourcePortRange * -DestinationPortRange *

$nsg | Set-AzNetworkSecurityGroup

---

Step 3: Declarative Bicep Template

Use the following reusable Bicep file to provision the SDN fabric declaratively:

param location string = 'centralus'
param vnetName string = 'SDN-VNet'
param vnetPrefix string = '10.10.0.0/16'
param subnetName string = 'TenantSubnet'
param subnetPrefix string = '10.10.1.0/24'

resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: { addressPrefixes: [vnetPrefix] }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: subnetPrefix
        }
      }
    ]
  }
}

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-02-01' = {
  name: '${vnetName}-nsg'
  location: location
  properties: {
    securityRules: [
      {
        name: 'AllowInternal'
        properties: {
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
          sourceAddressPrefix: subnetPrefix
          destinationAddressPrefix: subnetPrefix
          access: 'Allow'
          priority: 200
          direction: 'Inbound'
        }
      }
    ]
  }
}

output vnetId string = vnet.id
output subnetId string = vnet.properties.subnets[0].id

Deploy via CLI:

az deployment group create \
  --resource-group SDN-ResourceGroup \
  --template-file azure-local-sdn.bicep

---

Step 4: Integrating into CI/CD Pipelines

Azure Local automation fits into broader CI/CD strategies using GitHub Actions, Azure DevOps, or Jenkins. Here’s a simplified GitHub Actions job:

jobs:
  deploy-sdn:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install Bicep
        run: az bicep install

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Deploy SDN Infrastructure
        run: |
          az deployment group create \
            --resource-group SDN-ResourceGroup \
            --template-file azure-local-sdn.bicep

---

Real‑World Example: Multi‑Tenant SDN Provisioning

Scenario: An enterprise service provider manages three tenant environments, each requiring isolated SDN resources on shared Azure Local infrastructure.

Goal: Automate provisioning of VNets, ACLs, and service endpoints using templates and scripts for scale.

Steps Taken:

1. Deployed Network Controller and SLB via WAC wizard.
2. Created tenant-specific virtual networks and NSGs using parameterized PowerShell scripts.
3. Used Bicep templates to maintain consistent subnet naming and ACL policies across tenants.
4. Integrated deployment into a GitHub pipeline that triggers on pull requests for each tenant’s configuration repo.
5. Used Azure Arc to monitor each SDN deployment remotely, ensuring compliance and availability.

Outcome: Reduced provisioning time per tenant from ~2 hours (manual) to under 15 minutes, with complete audit trails and version control.

---

Best Practices & Common Pitfalls

Best Practices

• Use infrastructure-as-code (IaC) to enable versioning and peer review
• Standardize naming conventions for VNets, ACLs, and subnets
• Separate production and lab environments in different Bicep parameter files
• Use Git for source control of all templates and scripts
• Test with az what-if or bicep build to validate templates before deployment
• Monitor SDN endpoints using Azure Arc or third-party tools for health and security
• Tag all resources (e.g., Environment=Prod, Team=Networking) for governance

Common Pitfalls

• Overcomplicating ACL rules — Start simple, validate connectivity, then iterate
• Inconsistent MTU settings across physical and virtual networks can break SLB flows
• Improper SDN extension install on WAC leads to failed deployments
• Neglecting patching on NC/SLB/GW VMs can cause drift or bugs
• Forgetting to enable BGP/LLDP on physical switches can break external routing
• Mixing declarative (Bicep) and imperative (PowerShell) logic without coordination can lead to conflicts

---

Conclusion

Automating Azure Local SDN is no longer optional—it’s a strategic requirement for hybrid cloud success. With PowerShell, Bicep, and WAC working together, you can build secure, repeatable, and scalable SDN infrastructure that meets enterprise performance and compliance needs.

This guide gave you not just steps—but reusable templates, proven real-world implementation patterns, and a roadmap to integrate network automation into your DevOps ecosystem.

If you’re managing multiple tenants, SDN automation gives you a measurable ROI: faster time to deploy, stronger policy control, and repeatable governance.

What’s next?

• Implement these templates in your own lab
• Subscribe to our blog for future deep dives on Azure Local, SDN Federation, and CI/CD blueprints
• Have questions or feedback? Drop them in the comments or reach out via our contact page.

*The thoughts and opinions in this article are mine and hold no reflect on my employer*