I love Azure. It’s a great platform and I’m very happy with the continuing evolution of products and services offered. If you ever have to move resources to a different subscription, there are a lot of little things you have to think about, because sometimes settings are tied to a particular subscription or resource group (which is tied to a subscription).

Some of the non-profit organizations I’ve built applications for have taken advantage of Microsoft’s donation offerings, where they receive Microsoft products and services at a heavily discounted rate. However, these subscriptions often come with a time limit, after which they must be purchased again. When that happens, a new Azure subscription is created and you have to reassign any resources that are under the old subscription to the new one.

The easy part is actually reassigning the subscriptions. There are two ways I see to do this:

  1. Create a new resource group, assigning it to the new subscription ID, and then assign all of the resources you would like to that group
  2. Move the existing resource group to a new subscription. This works better in cases where you have resource groups well-defined
    1. Moving a resource group consists of choosing the resource group in the Azure portal and clicking the “Move,” as shown below:

The trickier part is figuring out any resources that may have been tied to the old resource group name or subscription. Here are a couple I have found:

  • SendGrid (and likely other external/third party applications that can’t use Azure credits) cannot be migrated from one subscription to another. A new API key must be generated for the application(s) of use.
  • Lets Encrypt certificates generated using the extension http://www.siteextensions.net/packages/letsencrypt (detailed in the post http://gagetrader.info/2016/09/27/lets-encrypt-azure-win/) have a couple of keys that are tied to the subscription Id and the resource group. The ones that need to be edited are (to view keys select the resource where the web job was registered from Azure portal -> Application Settings -> Keys section):
    • letsencrypt:SubscriptionId – 7dbf7306-25b3-4e5a-a85a-44017efb9cc5
    • letsencrypt:ResourceGroupName: (New Resource Group Name, if applicable)

    After you have completed this step, you will find that the web job fails with the following message the next time it runs:

    Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: Functions.RenewCertificate —> Microsoft.Rest.Azure.CloudException: The client ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ with object id ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ does not have authorization to perform action ‘Microsoft.Web/sites/config/list/action’ over scope ‘/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Web/sites/MySite/config/publishingcredentials’. at Microsoft.Azure.Management.WebSites.WebAppsOperations.

    This long message basically means that we need to assign the let’s encrypt principal created during the configuration of the extension with the Contributor role. This is fairly straightforward:

    1. Make sure Azure Powershell is installed on your machine (Open the Microsoft Web Platform Installer and find Microsoft Azure Powershell on the list if you don’t have it)
    2. Open Powershell as an administrator and sign in using the command:

      Login-AzureRmAccount

    3. Make sure your new Azure Subscription Id is selected. If not, run the following command:

      Select-AzureRmSubscription -SubscriptionId Your-Subscription-Id-Guid-Here

    4. Run the following command to assign the correct permissions to your new subscription Id:

      New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName Your-Service-Principal-Name-From-Extension-Setup

    Once that has been completed, the job should run again and be successful. Now your SSL certificates will continue to auto-renew.