• 4 min read

Using Azure Automation in Azure – everywhere

Today, the Microsoft Azure cloud platform is present across many different countries, and in multiple regions within most countries. This is commonly known as the Microsoft Azure public cloud.

Today, the Microsoft Azure cloud platform is present across many different countries, and in multiple regions within most countries. This is commonly known as the Microsoft Azure public cloud. In addition, to support China and US Federal government customers, Microsoft has other cloud platform offerings for these markets, named Azure China and Azure Government Cloud, respectively.

For the Azure Automation service, there are differences in the features offered between the Microsoft Azure public and other cloud platforms. This is mainly distinguished by what is offered through the Azure portal. In the Microsoft Azure public cloud, Azure Automation supports both Azure Service Management (portal) and Azure Resource Manager (portal) – and all the features that show up in both of these portals. However, in the Azure China and Azure Government clouds, Azure Automation only supports Azure Service Management and associated portals – and only the features that show up in those portals. For example, PowerShell script runbooks, and Azure Automation DSC are not supported in Azure China and the Azure Government cloud, at the time of writing this post.

When it comes to writing runbooks, the main difference between these Microsoft Azure public and other cloud platforms are the service endpoints (URIs). The difference can be subtle – Azure public cloud, Azure China cloud, and Azure Government cloud, for the Azure portal, for example. Management endpoints, storage endpoints, and others are slightly different as well. While Azure Automation ships in Azure, Azure China, and Azure Government cloud, using the same Azure Automation runbooks (PowerShell scripts/workflows) to target resources across the different Azure cloud platforms can be error-prone, due to the difference in service endpoints.

In this blog post, I’ll highlight the differences between each cloud and how to rectify your Azure Automation runbooks to work seamlessly between the many clouds that Microsoft Azure supports.

What are the different URIs used?

The following table highlights the different URIs for the same service in each Azure cloud.

Service

Azure

Azure China

Azure Government

Management API

management.core.windows.net

management.core.chinacloudapi.cn

management.core.usgovcloudapi.net

Storage

core.windows.net

core.chinacloudapi.cn

core.usgovcloudapi.net

Active Directory

login.windows.net

login.chinacloudapi.cn

login.windows.net

Resource Manager API

management.azure.com

management.chinacloudapi.cn

management.usgovcloudapi.net

Gallery

gallery.azure.com

gallery.chinacloudapi.cn

gallery.usgovcloudapi.net

How does one configure Azure Automation runbook to target different Azure clouds?

The prescribed way to connect your Azure Automation runbook for managing any Azure resource is first to use the Add-AzureAccount PowerShell cmdlet, which authenticates your Windows PowerShell session with your Azure account and subscription. If you have multiple subscriptions, you can then select the subscription to use by calling Select-AzureSubscription PowerShell cmdlet. If both calls succeed, then you are connected to your Azure subscription, and can start using any Azure PowerShell cmdlet to manage your Azure resources. This method works with Azure Service Management, which is available in all Azure clouds.

However, if you have downloaded a runbook sample from the Automation gallery or another source like Script Center, more likely than not the runbook sample will have used only the required parameters for Add-AzureAccount, which includes the credential parameter. Using only the credential parameter, the Add-AzureAccount cmdlet will default to the Azure public cloud environment. So, if you are using one of these runbooks in Azure China or the Azure Government cloud, the runbook will fail to run successfully.

In order to get your runbook to work correctly, you must define the Environment parameter as well.

For Azure China, a default environment called “AzureChinaCloud” already exists, and you can use this default environment when calling the Add-AzureAccount cmdlet with the Environment parameter.

Example of code:

    # Call to get the Azure Account to be available for Powershell
    # The Environment "AzureChinaCloud" is required to indicate URIs specific to Azure China cloud 
    Add-AzureAccount -Credential $AzureOrgIdCredential -Environment "AzureChinaCloud"

For Azure Government, you will need to create an environment that targets the Azure Government URIs using the Add-AzureEnvironment cmdlet, using the URIs described above. Take special note of the Name parameter value from Add-AzureEnvironment cmdlet. This is the same value you will need to pass in when calling the Add-AzureAccount cmdlet with the Environment parameter.

Example of code:

    # Add an environment where the Azure Account and Subscription resides   
    Add-AzureEnvironment `
        -Name "AzureGovernmentCloud" `
        -PublishSettingsFileUrl "https://manage.windowsazure.us/publishsettings/index?client=xplat" `
        -ServiceEndpoint "https://management.core.usgovcloudapi.net" `
        -ActiveDirectoryEndpoint "https://login.windows.net/" `
        -ActiveDirectoryServiceEndpointResourceId "https://management.core.usgovcloudapi.net/" `
        -GalleryEndpoint "https://gallery.usgovcloudapi.net" `
        -ManagementPortalUrl "https://manage.windowsazure.us" `
        -ResourceManagerEndpoint "https://management.usgovcloudapi.net" `
        -StorageEndpoint "core.usgovcloudapi.net" 
   
    # Call to get the Azure Account to be available for Powershell
    Add-AzureAccount -Credential $AzureOrgIdCredential -Environment "AzureGovernmentCloud"

After this, simply test your runbook. If it succeeds, then your runbook can successfully connect to the Azure cloud specified by the Add-AzureEnvironment cmdlet.

Sample Automation Runbook illustrating the above:

Consideration when using certificate based authentication

If you are not using Add-AzureAccount cmdlet, and instead rely on certificate based authentication, then you can try providing the same environment parameter when you are using the Set-AzureSubscription cmdlet with the Environment parameter.

In short, any Automation runbook targeting Azure Service Management functionality, written for Microsoft Azure public cloud, can work in either Azure China or the Azure Government cloud with only minor changes. Give it a try!

Just getting started with Azure Automation? Learn about the service here, and follow Azure Automation on Twitter.