Deploy a vanilla Azure Arc Data Controller in directly connected mode on AKS using an ARM Template

The following README will guide you on how to deploy a “Ready to Go” environment so you can start using Azure Arc-enabled data services deployed on Azure Kubernetes Service (AKS) cluster using Azure ARM Template.

By the end of this guide, you will have an AKS cluster deployed with an Azure Arc Data Controller and a Microsoft Windows Server 2022 (Datacenter) Azure VM, installed & pre-configured with all the required tools needed to work with Azure Arc Data Services:

Deployed Architecture

Note: Currently, Azure Arc-enabled data services with PostgreSQL Hyperscale is in public preview.


  • Clone the Azure Arc Jumpstart repository

    git clone
  • Install or update Azure CLI to version 2.15.0 and above. Use the below command to check your current installed version.

    az --version
  • Generate SSH Key (or use existing ssh key).

  • Create Azure service principal (SP)

    To be able to complete the scenario and its related automation, Azure service principal assigned with the “Contributor” role is required. To create it, login to your Azure account run the below command (this can also be done in Azure Cloud Shell.

    az login
    az ad sp create-for-rbac -n "<Unique SP Name>" --role contributor

    For example:

    az ad sp create-for-rbac -n "http://AzureArcData" --role contributor

    Output should look like this:

    "displayName": "AzureArcData",
    "name": "http://AzureArcData",

    Note: It is optional, but highly recommended, to scope the SP to a specific Azure subscription.

Automation Flow

For you to get familiar with the automation and deployment flow, below is an explanation.

  • User is editing the ARM template parameters file (1-time edit). These parameters values are being used throughout the deployment.

  • Main azuredeploy ARM template will initiate the deployment of the linked ARM templates:

    • VNET - Deploys a Virtual Network with a single subnet - used by our clientVM.
    • aks - Deploys the AKS cluster where all the Azure Arc data services will be deployed.
    • clientVm - Deploys the client Windows VM. This is where all user interactions with the environment are made from.
    • logAnalytics - Deploys Azure Log Analytics workspace to support Azure Arc-enabled data services logs uploads.
  • User remotes into client Windows VM, which automatically kicks off the DataServicesLogonScript PowerShell script that deploy and configure Azure Arc-enabled data services on the AKS cluster including the data controller.


As mentioned, this deployment will leverage ARM templates. You will deploy a single template that will initiate the entire automation for this scenario.

  • The deployment is using the ARM template parameters file. Before initiating the deployment, edit the azuredeploy.parameters.json file located in your local cloned repository folder. An example parameters file is located here.

    • sshRSAPublicKey - Your SSH public key
    • spnClientId - Your Azure service principal id
    • spnClientSecret - Your Azure service principal secret
    • spnTenantId - Your Azure tenant id
    • windowsAdminUsername - Client Windows VM Administrator name
    • windowsAdminPassword - Client Windows VM Password. Password must have 3 of the following: 1 lower case character, 1 upper case character, 1 number, and 1 special character. The value must be between 12 and 123 characters long.
    • myIpAddress - Your local public IP address. This is used to allow remote RDP and SSH connections to the client Windows VM and AKS cluster.
    • logAnalyticsWorkspaceName - Unique name for the deployment log analytics workspace.
    • deploySQLMI - Boolean that sets whether or not to deploy SQL Managed Instance, for this data controller only scenario we leave it set to false.
    • deployPostgreSQL - Boolean that sets whether or not to deploy PostgreSQL Hyperscale, for this data controller only scenario we leave it set to false.
    • kubernetesVersion - AKS version
    • dnsPrefix - AKS unique DNS prefix
  • To deploy the ARM template, navigate to the local cloned deployment folder and run the below command:

    az group create --name <Name of the Azure resource group> --location <Azure Region>
    az deployment group create \
    --resource-group <Name of the Azure resource group> \
    --name <The name of this deployment> \
    --template-uri \
    --parameters <The *azuredeploy.parameters.json* parameters file location>

    Note: Make sure that you are using the same Azure resource group name as the one you’ve just used in the azuredeploy.parameters.json file

    For example:

    az group create --name Arc-Data-Demo --location "East US"
    az deployment group create \
    --resource-group Arc-Data-Demo \
    --name arcdata \
    --template-uri \
    --parameters azuredeploy.parameters.json
    --parameters templateBaseUrl=""

    Note: The deployment time for this scenario can take ~15-20min

  • Once Azure resources has been provisioned, you will be able to see it in Azure portal. At this point, the resource group should have 8 various Azure resources deployed.

    ARM template deployment completed

    New Azure resource group with all resources

Windows Login & Post Deployment

  • Now that first phase of the automation is completed, it is time to RDP to the client VM using it’s public IP.

    Client VM public IP

  • At first login, as mentioned in the “Automation Flow” section above, the DataServicesLogonScript PowerShell logon script will start it’s run.

  • Let the script to run its course and do not close the PowerShell session, this will be done for you once completed. Once the script will finish it’s run, the logon script PowerShell session will be closed, the Windows wallpaper will change and the Azure Arc Data Controller will be deployed on the cluster and be ready to use.

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

PowerShell logon script run

  • Since this scenario is deploying the Azure Arc Data Controller, you will also notice additional newly deployed Azure resources in the resources group (at this point you should have 11 various Azure resources deployed. The important ones to notice are:

    • Azure Arc-enabled Kubernetes cluster - Azure Arc-enabled data services deployed in directly connected are using this type of resource in order to deploy the data services cluster extension as well as for using Azure Arc Custom locations.

    • Custom location - Provides a way for tenant administrators to use their Azure Arc-enabled Kubernetes clusters as target locations for deploying Azure services instances.

    • Azure Arc Data Controller - The data controller that is now deployed on the Kubernetes cluster.

Additional Azure resources in the resource group

  • Another tool automatically deployed is Azure Data Studio along with the Azure Data CLI, the Azure Arc and the PostgreSQL extensions. Using the Desktop shortcut created for you, open Azure Data Studio and click the Extensions settings to see both extensions.

    Azure Data Studio shortcut

Cluster extensions

In this scenario, the Azure Arc-enabled data services cluster extension was deployed and used throughout this scenario in order to deploy the data services infrastructure.

  • In order to view cluster extensions, click on the Azure Arc-enabled Kubernetes resource Extensions settings.

    Azure Arc-enabled Kubernetes resource

    Azure Arc-enabled Kubernetes cluster extensions settings


  • If you want to delete the entire environment, simply delete the deployment resource group from the Azure portal.

    Delete Azure resource group

Known Issues

  • Webhook pods go into error state, even after Data Controller/SQL MI/Postgres pods are up, caused by a known Helm-related backend issue that is being worked on. These errors can be safely ignored and do not impact the functionality of Azure Arc-enabled data services and the Jumpstart automation.

    webhook known issue