Using Azure Automation with Multiple Tenants

Welcome to a tale from the lab of Jon Warnken a Premier Field Engineer. 

I have been working with Azure Automation recently,  had a need for a runbook that required access in two different Azure Tenants. Because I had a virtual machine in one tenant (Tenant1) that is using a dynamic public IP address that is being used in a DNS zone record in another tenant (Tenant2), I need to update the record when the ip address changes. Now if the was in the same tenant as the zone this would be easy by making an alias record and map it to the public IP of the .

A quick search found a couple of existing runbooks that work with in the same tenant. After updating the code to use parameters and the Az modules this is runbook code I am using:

    [String]$RunAsAccount = "AzureRunAsConnection",
$connectionName = $RunAsAccount
$servicePrincipalConnection = Get-AutomationConnection -Name $connectionName
Connect-AzAccount -ServicePrincipal -TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint | out-null
Write-Output "Connecting to subscription:  $SubscriptionId1"
Select-AzSubscription -SubscriptionId $SubscriptionId1 | out-null
$VMIP = (Get-AzPublicIpAddress -ResourceGroupName $vmresourcegroup -Name $vmipname).IpAddress
Write-Output "VM Public Ip is $VMIP"
$DynDNS = $DNSrecord
#Get IP based on the Domain Name
[string]$MyDynamicIP = ([System.Net.DNS]::GetHostAddresses($DynDNS)).IPAddressToString
Write-Output "$DynDNS resolves to $MyDynamicIP"
If($VMIP -ne $MyDynamicIP){
    Write-Output "Connecting to subscription:  $SubscriptionId2"
    Select-AzSubscription -SubscriptionId $SubscriptionId2 | out-null
    $zone = Get-AzDnsZone -Name $DNSzone -ResourceGroupName $DNSresourcegroup
    $dnsrs = Get-AzDnsRecordSet -Zone $zone -Name $DNSrecordName -RecordType A
    $DNSIP = (Get-AzDnsRecordSet -Zone $zone -Name $DNSrecordName -RecordType A).Records.Ipv4Address
    Remove-AzDnsRecordConfig -RecordSet $dnsrs -Ipv4Address $DNSIP
    Add-AzDnsRecordConfig -RecordSet $dnsrs -Ipv4Address $VMIP
    Set-AzDnsRecordSet -RecordSet $dnsrs

If you would like to use this runbook, you will find it published on the PowerShell Gallery and can be imported into your automation account.

Up to this point I have been testing with in the same tenant and everything was working great. Because my automation account does not have any access in the other tenant, when I use a subscription id in Tenant2 the runbook will fail. Now I had to figure out how to this runbook in my second tenant. I considered three different options:

1 – Create an account in Tenant2; store the password in a key vault in Tenant1; have the runbook retrieve the password and use it to when needed for actions in Tenant2.

2 – Create an account in Tenant1; add the account as a guest user in Tenant2; use the account to execute the runbook.

3 – Delegate the automation account's run as account in Tenant 2. 

Option 1 worked when manually testing the code but ran into context and timing issues when executing via the automation account. This approach also has security and operational risks that would not make it acceptable for a production environment.

Option 2 worked when manually testing but still failed when executing in the context of the automation account.

The manual testing of the other options showed that it was possible to do automate this. It just needed to be delegated correctly. Enter Azure Lighthouse, this is how partners provide managed services in Azure. But the functionality can also be used by enterprises with multiple tenants. I decided to onboard via an Azure Resource Manager template. The process and sample template are available at

The only challenge I had was getting the principal id for my automation run as account. The run as account exists as an application and a managed application in Azure Active Directory. If you go the portal and look up the application you will see the Managed application instance.


  Clicking on that link will allow you to discover the correct object id to use with your ARM template.

Armed this and the role id you want to delegate complete the parameter json file and onboard the delegation in the target tenant. I used the resource group delegation template option

And setup the parameter file to delegate a user with owner access and my automation account with dns zone contributor access.

    "$schema": "",
    "contentVersion": "",
    "parameters": {
        "mspOfferName": {
            "value": "Fabrikam Managed Services - MrBoDean"
        "rgName": {
            "value": "Your resource group name"
        "mspOfferDescription": {
            "value": "Fabrikam Managed Services - MrBoDean"
        "managedByTenantId": {
            "value": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
        "authorizations": {
            "value": [
                    "principalId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy",
                    "roleDefinitionId": "8e3af657-a8ff-443c-a75c-2fe8c4bcb635",
                    "principalIdDisplayName": "Your User Name"
                    "principalId": "cccccccc-cccc-cccc-cccc-cccccccccccc",
                    "roleDefinitionId": "befefa01-2a29-4197-83a8-272ff33ce314",
                    "principalIdDisplayName": "Your Automation Account User"

Now this runbook can check and update the DNS record in the remote tenant.

Hopefully you find this useful and happy automating.

The sample are not supported under any Microsoft standard support program or service. The sample are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.


This article was originally published by Microsoft's Azure Blog. You can find the original article here.