Microsoft Azure - Commitment Management Setup Script

​

Overview

The Commitment Management setup script is the automated way to do Run the setup (steps A and B) for Azure Commitment Management. You copy one line from the nOps wizard into Azure Cloud Shell, and it downloads and runs the script. It sets up exactly what the portal steps set up, with the same template and names. Nothing more. Choose it in the wizard at Commitment Management → Run Setup → Run an Azure CLI script. The other choice, Step by step, is the portal walkthrough. Both end at the same place, and you can switch between them at any time. In short, the script:

• Shows what it will do, and what your account is allowed to do, before it changes anything.
• Does every step your account can do, and skips the ones it can’t (it doesn’t fail on them).
• Ends with a numbered list of what is left. For each item it says who can do it, where in the Azure portal, and the exact command with your values filled in.
• Is safe to run again, on any day and by anyone. It checks each step, keeps what is already there, and never creates anything twice.
• Never changes a delegation that is already there, even one from an earlier nOps setup.
• Gives the nOps.io application no role at all. Purchasing access goes to nOps staff, through Azure Lighthouse, on the subscriptions you choose.

---

​

What the script sets up

The delegation uses the same template, from the same address, and the same deployment name (nops-commitment-management) as Deploy to Azure and the Cloud Shell command in Step by step. You see it under Service providers in the Azure portal, where you can remove it at any time.

​

Exactly the same access as the manual setup

It never assigns Owner, Contributor, User Access Administrator, any billing role, any tenant-level reservation or savings plan role, or anything on the export storage account. Purchase policies are the only billing setting it touches, and only from off to on. nOps tests this on every change to the script. For every role ID and what it allows, see Permissions & Resources.

​

What the script never does

• It never changes an existing delegation. Redeploying a Lighthouse delegation replaces its roles, and some earlier nOps setups gave different roles. The script reports what such a delegation gives and prints the command that would update it, for you to decide. See Delegations already in place.
• It never turns a purchase policy off, and never changes any other policy setting. It reads the policies, changes only a purchase policy that is off, and writes every other setting back as it was. It prints the old values.
• It never deletes anything.
• It never buys anything. nOps staff buy later, in the Azure portal, through the delegation.
• It never stores or sends your Azure credentials. It runs as you, in your own Azure CLI session.

---

​

How it works

1. You copy the command. nOps saves the script for your setup, built from what you entered in the wizard.
2. You run it in your own Azure CLI session. The command downloads the script, saves it as nops-azure-cm-setup.sh and runs it. Every change is made by your account, so Azure’s activity log shows you made it.
3. The script reports each step’s result to nOps: done, skipped, needs another role, or the Azure error code with a one-line message. That’s all it sends. If nOps can’t be reached, setup carries on.
4. nOps checks your tenant on its own, as the nOps.io application, with the read access it already has from Savings Analysis. The checklist ticks off the delegation and the purchase policies as Azure shows them.
5. When both are in place, nOps runs Verify for you and turns Commitment Management on. Savings Analysis stays on the whole time.

​

One run, step by step

---

​

Before you start

​

Who should run it

The script does what the signed-in account is allowed to do. One person with both roles below finishes in one run. Otherwise, run it as one person, then have the next person run the same script. Steps already done are kept. The script checks Owner before it starts, so a [needs] there is certain. For the purchase policies, Azure doesn’t tell an account in advance whether a billing role reaches it through a group, so the script tries them: if Azure refuses, the step becomes [needs] and goes on the to-do list.

​

Three ways to run it

All three run the same script. Turn on Preview only to get the preview the same three ways.

​

What to check in nOps first

• Purchase subscriptions (step 1): one per billing profile you want nOps to buy for (one in total for EA). The script uses exactly these.
• Billing account ID (MCA, in Run Setup): filled in from Savings Analysis. The script uses it to find each subscription’s billing profile when step 1 doesn’t name one. Correct it there if it’s wrong; the change is used for the script only.

---

​

Run it

---

​

Reading the output

The summary always ends with one of:

• Setup is done. nOps finishes on its own.
• A numbered list. Each item says what is left, who can do it, the portal path, and the exact Azure CLI command with your values. Do them, or send the list to the person it names, then run the same script again.

---

​

Delegations already in place

Some customers have a delegation from an earlier nOps setup (“nOps FinOps Management (Dedicated Subscription)”). It has the same name in Azure as today’s delegation, and deploying the template again would replace its roles. So the script never redeploys one that is already there. It reads what the delegation gives nOps staff and: Updating a delegation is your decision. The update command replaces its roles with today’s three. If Azure rejects the update, remove the old delegation under Service providers in the Azure portal, then run the script again.

---

​

Running it again

Run it as often as you like: after fixing something by hand, as another person, or after adding a purchase subscription in step 1 (copy the command again so the script includes it). Every run:

• reads the delegation on each purchase subscription and the purchase policies on each enrollment or billing profile before changing anything;
• keeps what is in place, and only does what is left;
• never deploys a delegation on a subscription that already has one with other roles;
• writes a purchase policy only when a purchase setting is off.

---

​

What the script sends to nOps

The same as the Savings Analysis script: for each step, done, skipped, needs another role, or failed, with the Azure error code and a one-line message. It sends no credentials, tokens, resource contents, cost data or personal data. The script and the one-line command use one single-purpose token. It can post step results for your integration and download the script you saved, nothing else. It expires after 3 days, and nOps stores it only as a hash. The preview never sends anything.

---

​

Troubleshooting

​

Before any change is made

​

During the steps

​

On the nOps setup page

---

​

Undoing the setup

• Delegation: in the Azure portal, open Service providers → Service provider offers, select nOps Commitment Management, and delete it, or ask nOps to remove it. Removing it stops nOps staff from buying through that subscription. Commitments already bought keep applying.
• Purchase policies: set them back under Cost Management + Billing → Billing scopes → the enrollment or billing profile → Policies. The script printed the old values when it changed them.

---

​

FAQs