{"id":5630,"date":"2015-02-04T00:00:00","date_gmt":"2015-02-04T08:00:00","guid":{"rendered":""},"modified":"2025-09-16T12:28:54","modified_gmt":"2025-09-16T19:28:54","slug":"managing-on-premises-systems-with-azure-automation","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/managing-on-premises-systems-with-azure-automation\/","title":{"rendered":"Managing On-Premises Systems with Azure Automation"},"content":{"rendered":"\n

[UPDATE: This blog has been “deprecated” by the release of the Hybrid Runbook Worker <\/a>feature. This feature provides a first-class way to achieve the functionality described here. Check it out!]<\/em><\/p>\n\n\n\n

Thanks to the Windows PowerShell Remoting feature, Azure Automation can not only manage your Azure resources at an infrastructural level, but also reach inside VMs and execute commands<\/a>. However, PowerShell Remoting is not always a viable option \u2013 perhaps a public WinRM port on your Azure VM cannot be opened for security reasons, or perhaps your VMs are strictly on-premises and therefore unreachable from Azure Automation. If you find yourself in one of these situations, all hope is not lost!<\/p>\n\n\n\n

In the first case, where you have Azure-hosted VMs but cannot open a public WinRM port, the solution is simple. A recent Microsoft blog post<\/a> provides a runbook for running PowerShell commands on such VMs by utilizing the Azure VM Agent\u2019s Custom Script Extension<\/a>.<\/p>\n\n\n\n

In this post, we present an extension to this solution which handles the second case \u2013 where your VMs are on-premises. If you have an on-premises network connected to an Azure virtual network<\/a>, our solution will enable you to manage on-premises VMs from Azure Automation! And it does so with just a single runbook. But first, a little bit of setup is required\u2026<\/p>\n\n\n\n

Configuring Your Environment<\/h2>\n\n\n\n

Our runbook depends on a few resources being present in your Azure environment: a \u201cProxy VM\u201d, an Azure Storage Account, and a certificate installed both in Azure Automation and on your Proxy VM (for security reasons, explained below).<\/p>\n\n\n\n

\u201cProxy VM\u201d<\/h3>\n\n\n\n

The \u201cProxy VM\u201d is an Azure VM which will be used to invoke commands on other machines in its network \u2013 it is the mechanism by which Azure Automation will interact with these machines, hence \u201cproxy\u201d. The Proxy VM must have the Azure VM Agent installed. This agent is installed by default when an Azure VM is created, so most likely you already have such a machine. If you need to install the agent on an existing VM, you can learn how to do so from this<\/a> blog post.<\/p>\n\n\n\n

Running our runbook will enable the VM Agent\u2019s Custom Script Extension on the Proxy VM you specify, which allows that VM to download and execute scripts stored in an Azure Storage Account. Note that the Proxy VM will use PowerShell Remoting to communicate with other VMs in its network, so those VMs must have WinRM ports open to the network.<\/p>\n\n\n\n

The Proxy VM is what enables management of on-premises machines<\/strong>, since Azure Virtual Networks can be connected to on-premises networks (details here<\/a>). If you have such a network, and use an Azure VM belonging to it as your Proxy VM, then that VM will be able to run commands on your on-premises machines.<\/p>\n\n\n\n

Azure Storage Account<\/h3>\n\n\n\n

The Custom Script Extension (running on the Proxy VM) downloads scripts from a given Azure Storage account, so you will need to have one in your Azure environment. You can create a specific container for the extension to use, or allow the runbook to create and use a default container.<\/p>\n\n\n\n

Certificate<\/h3>\n\n\n\n

Since our runbook enlists a Proxy VM to execute PowerShell on other machines, it will need to know what credentials to use to do so. However, we don\u2019t want these credentials sitting around in plain text, so the runbook needs a way to encrypt them before they are baked into a script and handed off to Azure Storage (and ultimately, to the Proxy VM). The Proxy VM will then need to decrypt the credentials at runtime. So, our runbook requires a certificate to be installed both in Azure Automation and on the Proxy VM.<\/p>\n\n\n\n

    \n
  1. Create the certificate:<\/strong> You will need to create a .pfx certificate to install on your Proxy VM. Either that certificate or its corresponding .cer certificate will also need to be uploaded to Azure Automation. For instructions on creating a certificate, see this<\/a> page.<\/li>\n\n\n\n
  2. Upload the certificate to Azure Automation:<\/strong> In the Azure portal, navigate to the Automation service, choose your Automation Account, and click on the Assets tab. At the bottom of the page, click \u201cAdd Setting\u201d and you should see this wizard appear:
    \"graphical
    Click on \u201cAdd Credential\u201d and configure it like so:
    \"graphical<\/li>\n\n\n\n
  3. On the last page of the wizard, upload your certificate file. For security reasons, you should upload the .cer certificate to Azure Automation (since it lacks the private key, which Azure Automation doesn\u2019t need). Either the .cer or .pfx file will work, but if you upload the .pfx, please note that it should not<\/strong> be marked as exportable in Azure Automation.<\/li>\n\n\n\n
  4. Install the certificate into the certificate store on your Proxy VM:<\/strong> Copy your .pfx certificate onto the Proxy VM, and double-click the file to start the import process. Make sure you select \u201cLocal Machine\u201d for the Store Location, and place the certificate in the Personal store (Cert:LocalMachineMy). This is where the code run by the Custom Script Extension will look to decrypt the credentials it needs. Using this location creates an important security boundary: only Administrators and SYSTEM can access the private keys of certificates in this store. This prevents unauthorized users from decrypting credentials used by the runbook after they are sent to the Proxy VM.<\/li>\n<\/ol>\n\n\n\n

    Congratulations, you are now ready to\u2026<\/p>\n\n\n\n

    Run the Runbook!<\/h2>\n\n\n\n

    Now that you have the requisite resources available, it\u2019s time to run some code! Grab the runbook from Script Center<\/a> or the Azure Automation Runbook Gallery<\/a>.<\/p>\n\n\n\n

    Here\u2019s an example call to this runbook:<\/p>\n\n\n

    \n$Results = Invoke-CommandViaProxy `\n        -ProxyVmName VM01 `\n        -ProxyServiceName VM01 `\n        -ScriptBlock \"{ 'Hello, my name is '; `$env:COMPUTERNAME}\" `\n        -TargetComputers VM02,VM03 `\n        -RunAsCredential $NetworkCred `\n        -CertificateAssetName \"MyProxyVmCert\" `\n        -AzureOrgIdCredential $OrgCred `\n        -AzureSubscriptionName $SubscriptionName `\n        -StorageAccountName $StorageAccountName\n<\/pre><\/div>\n\n\n
    And explanations of the parameters involved:<\/p>\n\n\n\n