After you onboard a subscription (or resource group) to Azure Lighthouse, you might need to make changes. For example, your customer might want you to take on additional management tasks that require a different Azure built-in role, or you might need to change the tenant to which a customer subscription is delegated.
Tipp
Though we refer to service providers and customers in this topic, enterprises managing multiple tenants can use the same process to set up Azure Lighthouse and consolidate their management experience.
To change authorizations only: You can update your delegation by changing the authorizations section of the ARM template.
To change the managing tenant: You must create a new ARM template with a different mspOfferName from your previous offer.
Update your ARM template
To update your delegation, you need to deploy an ARM template that includes the changes you'd like to make.
If you're only updating authorizations (such as adding a new user group with a role you hadn't previously included, or changing the role for an existing user), you can use the same mspOfferName as in the ARM template that you used for the previous delegation. Use your previous template as a starting point. Then, make the changes you need, such as replacing one Azure built-in role with another, or adding a new authorization to the template.
In most cases, we recommend having only one mspOfferName in use by the same customer and managing tenant. You don't need to change the mspOfferName if the managing tenant remains the same. If you do change the mspOfferName, this will be considered a new, separate offer. Changing the mspOfferName is required if you're switching to a different the managing tenant.
Remove the previous delegation
Before performing a new deployment, you may want to remove access to the previous delegation. This ensures that all previous permissions are removed, allowing you to start clean with the exact users/groups and roles that should apply going forward.
If you're changing the managing tenant, you should only leave the previous offer in place if you want both tenants to continue to have access. If you want the new managing tenant to be the only tenant that has access, the earlier offer must be removed. We generally recommend removing the previous offer before you deploy the new one.
Wichteg
If you use a new mspOfferName and keep any of the same principalId values, you must remove access to the previous delegation before deploying the new offer. If you don't remove the previous offer first, users who had previously been granted permissions may lose access completely due to conflicting assignments.
If you're updating the offer only to adjust authorizations, and keeping the same mspOfferName, you don't have to remove the previous delegation. The new deployment will replace the previous delegation, and only the authorizations in the newest template will apply.
If you removed the previous delegation but are unable to deploy the new ARM template, you might need to remove the previous registration definition completely. This can be done by any user with a role that has the Microsoft.Authorization/roleAssignments/write permission, such as Owner, in the customer tenant.
Deploy the ARM template
Your customer can deploy the updated template in the same way that they did previously: in the Azure portal, by using PowerShell, or by using Azure CLI.
After the deployment is complete, confirm that it was successful. If so, the updated authorizations are in effect for the subscription or resource group(s) that the customer has delegated.
We recommend that you avoid having multiple Managed Service offers between the same customer and managing tenant. If you publish a new offer for a current customer that uses the same managing tenant, be sure that the earlier offer is removed before the customer accepts the newer offer.