Sometimes you need to target a management group id, e.g. when you import a policy definition and want to select a management group as the policy definition scope. I discovered that sometimes people struggle with this procedure when using the management group name or id.

If you create a management group you need to define a display name, a management group id and the parent management group. When creating management groups in the portal, people tend to use the same value for the display name and the id.

After creating the management group it can now be used as a target. In this example I import a policy definition and set the scope to the newly created management group by using the group id.

az policy definition create –rules .\Policy.json –params .\PolicyParameters.json –management-group p-mag-infrastructure –name p-pod-allowedlocationsdemo-01

In this case the import works because the management group id and the display name are identical. The command however was referencing to the group id, not the display name. If you try to use the root management group as the scope, the command will fail. Unfortunately, the output makes you think that everything worked, but it did not. You will not find the policy definition anywhere.

az policy definition create –rules .\Policy.json –params .\PolicyParameters.json –management-group d-mag-root-01 –name p-pod-allowedlocationsdemo-02

Why? For the root management group it’s a bit different because it’s pre-created group at the tenant level. Going to the details clearly shows, that id and display name are not identical. The id is a Guid, the name is a human readable name (that can be changed if needed).

Using the proper guid of the management group instead of the display name makes the command work.

az policy definition create –rules .\Policy.json –params .\PolicyParameters.json –management-group 74bb1493-d41e-xxxx-xxxx-xxxxxxxxxxxx –name p-pod-allowedlocationsdemo-02

So you always need to target the group id. My advice to make sure you don’t get confused too much: you should definitely follow the root management group approach and best practice here and use a real Guid for the management group id. When using the portal, just create a Guid first and paste it to the id property. Or (even better), create management groups by using code, e.g. by using the Azure CLI.

az account management-group create –name (new-guid) –display-name t-mag-test-01 –parent 74bb1493-d41e-xxxx-xxxx-xxxxxxxxxxxx

Cheers
Marcel