Wat zijn Azure-beheergroepen?What are Azure management groups?

Als uw organisatie veel abonnementen heeft, moet u de toegang, beleidsregels en naleving voor deze abonnementen op een efficiënte manier kunnen beheren.If your organization has many subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure-beheergroepen bieden een scopeniveau boven abonnementen.Azure management groups provide a level of scope above subscriptions. U ordent abonnementen in containers, zogenaamde 'beheergroepen', en past uw governancevoorwaarden hierop toe.You organize subscriptions into containers called "management groups" and apply your governance conditions to the management groups. Alle abonnementen in een beheergroep nemen automatisch de voorwaarden over die op de beheergroep zijn toegepast.All subscriptions within a management group automatically inherit the conditions applied to the management group. Beheergroepen bieden u beheer van bedrijfskwaliteit op grote schaal, ongeacht de typen abonnementen die u hebt.Management groups give you enterprise-grade management at a large scale no matter what type of subscriptions you might have. Alle abonnementen binnen een beheergroep moeten afhankelijk zijn van dezelfde Azure Active Directory-tenant.All subscriptions within a single management group must trust the same Azure Active Directory tenant.

U kunt bijvoorbeeld beleid toepassen op een beheergroep, dat het aantal regio's beperkt dat beschikbaar is voor het maken van virtuele machines (VM’s).For example, you can apply policies to a management group that limits the regions available for virtual machine (VM) creation. Dit beleid wordt dan toegepast op alle beheergroepen, abonnementen en resources onder die beheergroep, doordat het ervoor zorgt dat er alleen VM’s kunnen worden gemaakt in die regio.This policy would be applied to all management groups, subscriptions, and resources under that management group by only allowing VMs to be created in that region.

Hiërarchie van managementgroepen en abonnementenHierarchy of management groups and subscriptions

U kunt een flexibele structuur van managementgroepen en abonnementen bouwen om uw resources in een hiërarchie te ordenen voor uniform beleid en toegangsbeheer.You can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management. Het volgende diagram laat een voorbeeld zien van hoe een hiërarchie voor governance kan worden gemaakt met behulp van beheergroepen.The following diagram shows an example of creating a hierarchy for governance using management groups.

Diagram van een voorbeeld van een hiërarchie voor beheergroepen.

Diagram van een hoofdbeheergroep met zowel beheergroepen als abonnementen.Diagram of a root management group holding both management groups and subscriptions. Sommige onderliggende beheergroepen bevatten beheergroepen, sommige abonnementen en sommige beide.Some child management groups hold management groups, some hold subscriptions, and some hold both. Een van de voorbeelden in de voorbeeldhiërarchie is vier niveaus van beheergroepen waarbij het onderliggende niveau alle abonnementen is.One of the examples in the sample hierarchy is four levels of management groups with the child level being all subscriptions.

U kunt een hiërarchie maken waarmee een beleid wordt toegepast, bijvoorbeeld om VM-locaties tot de regio US - west te beperken in de groep 'Productie'.You can create a hierarchy that applies a policy, for example, which limits VM locations to the US West Region in the group called "Production". Dit beleid is van toepassing op alle Enterprise Agreement-abonnementen die afgeleid zijn van die beheergroep en worden toegepast op alle VM's onder die abonnementen.This policy will inherit onto all the Enterprise Agreement (EA) subscriptions that are descendants of that management group and will apply to all VMs under those subscriptions. Dit beveiligingsbeleid kan niet worden gewijzigd door de eigenaar van de resource of het abonnement, wat zorgt voor betere governance.This security policy cannot be altered by the resource or subscription owner allowing for improved governance.

Een ander scenario waarbij u beheergroepen kunt gebruiken, is om gebruikers toegang te geven tot meerdere abonnementen.Another scenario where you would use management groups is to provide user access to multiple subscriptions. Als u meerdere abonnementen naar de desbetreffende beheergroep verplaatst, kunt u één Azure-roltoewijzing in de beheergroep maken, die de toegang doorgeeft aan alle abonnementen.By moving multiple subscriptions under that management group, you can create one Azure role assignment on the management group, which will inherit that access to all the subscriptions. Eén toewijzing in de beheergroep kan gebruikers toegang geven tot alles wat ze nodig hebben. Er hoeven dan geen scripts te worden geschreven voor Azure RBAC-toewijzingen in meerdere abonnementen.One assignment on the management group can enable users to have access to everything they need instead of scripting Azure RBAC over different subscriptions.

Belangrijke feiten over beheergroepenImportant facts about management groups

  • In één map kunnen 10.000 beheergroepen worden ondersteund.10,000 management groups can be supported in a single directory.
  • Een beheergroepstructuur ondersteunt tot wel zes niveaus.A management group tree can support up to six levels of depth.
    • Deze limiet is exclusief het hoofdniveau of het abonnementsniveau.This limit doesn't include the Root level or the subscription level.
  • Een beheergroep of abonnement biedt ondersteuning voor slechts één bovenliggend item.Each management group and subscription can only support one parent.
  • Elke beheergroep kan een groot aantal onderliggende items hebben.Each management group can have many children.
  • Alle abonnementen en beheergroepen bevinden zich in één hiërarchie in elke map.All subscriptions and management groups are within a single hierarchy in each directory. Zie Belangrijke feiten over de hoofdbeheergroep.See Important facts about the Root management group.

Hoofdbeheergroep voor elke mapRoot management group for each directory

Elke map krijgt één beheergroep op het hoogste niveau, de 'hoofdbeheergroep'.Each directory is given a single top-level management group called the "Root" management group. Deze hoofdbeheergroep is zo in de hiërarchie ingebouwd dat alle beheergroepen en abonnementen hierin zijn opgevouwen.This root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. Met deze hoofdbeheergroep kunt u algemene beleidsregels en Azure-roltoewijzingen toepassen op mapniveau.This root management group allows for global policies and Azure role assignments to be applied at the directory level. De globale beheerder van Azure AD moet eerst de rol Beheerder gebruikerstoegang van deze hoofdgroep aan zichzelf toewijzen.The Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. Nadat hij dit heeft gedaan, kan de beheerder een Azure-rol toewijzen aan andere directory-gebruikers of -groepen om de hiërarchie te beheren.After elevating access, the administrator can assign any Azure role to other directory users or groups to manage the hierarchy. Als beheerder kunt u uw eigen account toewijzen als eigenaar van de hoofdbeheergroep.As administrator, you can assign your own account as owner of the root management group.

Belangrijke feiten over de hoofdbeheergroepImportant facts about the Root management group

  • Standaard is de weergavenaam van de hoofdbeheergroep Tenanthoofdgroep.By default, the root management group's display name is Tenant root group. De id is de Azure Active Directory-id.The ID is the Azure Active Directory ID.
  • Als u de weergavenaam wilt wijzigen, moet uw account de rol Eigenaar of Inzender in de hoofdbeheergroep hebben toegewezen gekregen.To change the display name, your account must be assigned the Owner or Contributor role on the root management group. Zie Change the name of a management group (De naam van een beheergroep wijzigen) om de naam van een beheergroep bij te werken.See Change the name of a management group to update the name of a management group.
  • In tegenstelling tot andere beheergroepen kan de hoofdbeheergroep niet worden verplaatst of verwijderd.The root management group can't be moved or deleted, unlike other management groups.
  • Alle abonnementen en beheergroepen kunnen worden samengevouwen in deze ene hoofdbeheergroep binnen de map.All subscriptions and management groups fold up to the one root management group within the directory.
    • Alle resources in de map kunnen worden samengevouwen in de hoofdbeheergroep voor algemeen beheer.All resources in the directory fold up to the root management group for global management.
    • Wanneer er een nieuw abonnement wordt gemaakt, wordt dit standaard automatisch in de hoofdbeheergroep geplaatst.New subscriptions are automatically defaulted to the root management group when created.
  • Alle Azure-klanten kunnen de hoofdbeheergroep zien, maar niet alle klanten hebben de mogelijkheid om die hoofdbeheergroep te beheren.All Azure customers can see the root management group, but not all customers have access to manage that root management group.
    • Iedereen die toegang heeft tot een abonnement, kan de context zien van waar dat abonnement zich in de hiërarchie bevindt.Everyone who has access to a subscription can see the context of where that subscription is in the hierarchy.
    • Niemand krijgt standaard toegang tot de hoofdbeheergroep.No one is given default access to the root management group. Globale beheerders van Azure AD zijn de enige gebruikers die zichzelf toegang kunnen verschaffen.Azure AD Global Administrators are the only users that can elevate themselves to gain access. Wanneer ze toegang hebben tot de hoofdbeheergroep, kunnen de globale beheerders elke Azure-rol toewijzen aan andere gebruikers, zodat deze het beheer daarover hebbenOnce they have access to the root management group, the global administrators can assign any Azure role to other users to manage
      .it.
  • In SDK fungeert de hoofdbeheergroep, of tenanthoofdmap, als een beheergroep.In SDK, the root management group, or 'Tenant Root', operates as a management group.

Belangrijk

Toewijzingen voor gebruikerstoegang of beleidstoewijzingen in de hoofdbeheergroep zijn van toepassing op alle resources in de map.Any assignment of user access or policy assignment on the root management group applies to all resources within the directory. Daarom moeten alle klanten goed nadenken over de noodzaak om items op dit niveau toe te wijzen.Because of this, all customers should evaluate the need to have items defined on this scope. Op dit niveau mogen alleen toewijzingen voor gebruikerstoegang of beleid de aanduiding 'Must have' (Strikt noodzakelijk) hebbenUser access and policy assignments should be "Must Have" only at this
.scope.

Eerste installatie van beheergroepenInitial setup of management groups

Wanneer een gebruiker start met het gebruik van beheergroepen, vindt er een proces plaats voor de eerste installatie.When any user starts using management groups, there's an initial setup process that happens. Eerst wordt er een hoofdbeheergroep gemaakt in de map.The first step is the root management group is created in the directory. Zodra deze groep klaar is, worden alle bestaande abonnementen die in de map zijn opgenomen gemaakt tot onderliggende items van de hoofdbeheergroep.Once this group is created, all existing subscriptions that exist in the directory are made children of the root management group. De reden dat dit proces zo werkt, is om er zeker van te zijn dat er binnen een map slechts één beheergroephiërarchie is.The reason for this process is to make sure there's only one management group hierarchy within a directory. Die ene hiërarchie in de map zorgt ervoor dat klanten met een beheerdersrol globale toegang en beleidsregels kunnen toepassen waar andere klanten in de map niet omheen kunnen.The single hierarchy within the directory allows administrative customers to apply global access and policies that other customers within the directory can't bypass. Alle zaken die in de hoofdmap zijn toegewezen, zijn van toepassing op de hele hiërarchie, en dus op alle beheergroepen, abonnementen, resourcegroepen en resources binnen die Azure AD-tenant.Anything assigned on the root will apply to the entire hierarchy, which includes all management groups, subscriptions, resource groups, and resources within that Azure AD Tenant.

Problemen met de weergave van alle abonnementenTrouble seeing all subscriptions

Bij een aantal mappen die vroeg in de preview (vóór 25 juni 2018) met beheergroepen begonnen te werken, deed zich een probleem voor waarbij niet alle abonnementen zich in de hiërarchie bevonden.A few directories that started using management groups early in the preview before June 25 2018 could see an issue where not all the subscriptions were within the hierarchy. Het proces voor het onderbrengen van alle abonnementen in de hiërarchie werden geïmplementeerd nadat er een rol- of beleidstoewijzing was uitgevoerd in de hoofdbeheergroep in de map.The process to have all subscriptions in the hierarchy was put in place after a role or policy assignment was done on the root management group in the directory.

Het probleem oplossenHow to resolve the issue

U kunt dit probleem op twee manieren verhelpen.There are two options you can do to resolve this issue.

  • Alle rol- en beleidstoewijzingen uit de hoofdbeheergroep verwijderenRemove all Role and Policy assignments from the root management group
    • Door alle beleids- en roltoewijzingen van de hoofdbeheergroep te verwijderen, zal de service alle abonnementen in de hiërarchie aanvullen tijdens de volgende nachtelijke cyclus.By removing any policy and role assignments from the root management group, the service backfills all subscriptions into the hierarchy the next overnight cycle. Dankzij dit proces wordt er niet onbedoeld toegang verleend of beleid toegewezen aan alle abonnementen van de tenant.This process is so there's no accidental access given or policy assignment to all of the tenants subscriptions.
    • De beste manier om dit proces uit te voeren zonder uw services te beïnvloeden, is de rol- of beleidstoewijzingen één niveau onder de hoofdbeheergroep toe te passen.The best way to do this process without impacting your services is to apply the role or policy assignments one level below the Root management group. Vervolgens kunt u alle toewijzingen van het hoofdbereik verwijderen.Then you can remove all assignments from the root scope.
  • De API rechtstreeks aanroepen om het backfill-proces te startenCall the API directly to start the backfill process
    • Elke klant in de map kan de API's TenantBackfillStatusRequest en StartTenantBackfillRequest aanroepen.Any customer in the directory can call the TenantBackfillStatusRequest or StartTenantBackfillRequest APIs. Wanneer de API StartTenantBackfillRequest wordt aangeroepen, wordt hiermee het initiële instellingsproces gestart voor het verplaatsen van alle abonnementen naar de hiërarchie.When the StartTenantBackfillRequest API is called, it kicks off the initial setup process of moving all the subscriptions into the hierarchy. Met dit proces wordt ook afgedwongen dat alle nieuwe abonnementen een onderliggend element van de hoofdbeheergroep worden gemaakt.This process also starts the enforcement of all new subscription to be a child of the root management group. Dit proces kan worden uitgevoerd zonder de toewijzingen op het hoofdniveau te wijzigen.This process can be done without changing any assignments on the root level. Door de API aan te roepen, geeft u aan dat een beleids- of toegangstoewijzing in de hoofdmap mag worden toegepast op alle abonnementen.By calling the API, you're saying it's okay that any policy or access assignment on the root can be applied to all subscriptions.

Als u vragen hebt over dit backfill-proces, neemt u contact op met: managementgroups@microsoft.comIf you have questions on this backfill process, contact: managementgroups@microsoft.com

Toegang tot beheergroepenManagement group access

Azure-beheergroepen ondersteunen op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor alle soorten toegang tot resources en roldefinities.Azure management groups support Azure role-based access control (Azure RBAC) for all resource accesses and role definitions. Deze machtigingen worden overgenomen door onderliggende resources die in de hiërarchie zijn opgenomen.These permissions are inherited to child resources that exist in the hierarchy. Elke Azure-rol kan worden toegewezen aan een beheergroep die door alle onderliggende items in de hiërarchie voor de resources worden overgenomen.Any Azure role can be assigned to a management group that will inherit down the hierarchy to the resources. Zo kan de Azure-rol VM-inzender aan een beheergroep worden toegewezen.For example, the Azure role VM contributor can be assigned to a management group. Deze rol heeft geen actie in de beheergroep, maar wordt overgenomen door alle VM's in die beheergroep.This role has no action on the management group, but will inherit to all VMs under that management group.

In de volgende tabel staat een lijst met rollen en de acties die worden ondersteund in beheergroepen.The following chart shows the list of roles and the supported actions on management groups.

Naam van Azure-rolAzure Role Name MakenCreate Naam wijzigenRename Verplaatsen**Move** VerwijderenDelete Toegang toewijzenAssign Access Beleid toewijzenAssign Policy LezenRead
EigenaarOwner XX XX XX XX XX XX XX
InzenderContributor XX XX XX XX XX
Beheergroep-inzender*MG Contributor* XX XX XX XX XX
LezerReader XX
Beheergroep-lezer*MG Reader* XX
Inzender voor resourcebeleidResource Policy Contributor XX
Beheerder van gebruikerstoegangUser Access Administrator XX XX

*: Met de rollen Beheergroep-inzender en Beheergroep-lezer kunnen gebruikers deze acties alleen uitvoeren op beheergroepniveau.*: MG Contributor and MG Reader only allow users to do those actions on the management group scope.
**: Bij roltoewijzingen hoeft er geen abonnement of beheergroep van of naar de hoofdbeheergroep te worden verplaatst.**: Role Assignments on the Root management group aren't required to move a subscription or management group to and from it. Zie Uw resources beheren met beheergroepen voor meer informatie over het verplaatsen van items binnen de hiërarchie.See Manage your resources with management groups for details on moving items within the hierarchy.

Aangepaste roldefinitie en -toewijzing van AzureAzure custom role definition and assignment

Ondersteuning voor aangepaste rollen van Azure voor beheergroepen is momenteel in de preview-versie beschikbaar met enkele beperkingen.Azure custom role support for management groups is currently in preview with some limitations. U kunt het bereik van de beheergroep definiëren in het toewijsbare bereik van de roldefinitie.You can define the management group scope in the Role Definition's assignable scope. Die aangepaste rol van Azure is dan beschikbaar voor toewijzing in die beheergroep en alle beheergroepen, abonnementen, resourcegroepen en resources daaronder.That Azure custom role will then be available for assignment on that management group and any management group, subscription, resource group, or resource under it. Deze aangepaste rol neemt machtigingen over in de hiërarchie op dezelfde manier als een ingebouwde rol.This custom role will inherit down the hierarchy like any built-in role.

VoorbeelddefinitieExample definition

Het definiëren en maken van een aangepaste rol verandert niet met het opnemen van beheergroepen.Defining and creating a custom role doesn't change with the inclusion of management groups. Gebruik het volledige pad om de beheergroep te definiëren: /providers/Microsoft.Management/managementgroups/{groupId} .Use the full path to define the management group /providers/Microsoft.Management/managementgroups/{groupId}.

Gebruik de id van de beheergroep en niet de weergavenaam van de beheergroep.Use the management group's ID and not the management group's display name. Deze fout wordt vaak gemaakt omdat beide aangepaste velden zijn bij het maken van een beheergroep.This common error happens since both are custom-defined fields when creating a management group.

...
{
  "Name": "MG Test Custom Role",
  "Id": "id", 
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementgroups/delete",
    "Microsoft.Management/managementgroups/read",
    "Microsoft.Management/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

Problemen met het verbreken van de roldefinitie en het toewijzingshiërarchiepadIssues with breaking the role definition and assignment hierarchy path

Roldefinities kunnen overal binnen de hiërarchie van de beheergroep worden toegewezen.Role definitions are assignable scope anywhere within the management group hierarchy. Een roldefinitie kan worden gedefinieerd in een bovenliggende beheergroep terwijl de daadwerkelijke roltoewijzing bestaat op het onderliggende abonnement.A role definition can be defined on a parent management group while the actual role assignment exists on the child subscription. Omdat er een relatie bestaat tussen de twee items, ontvangt u een foutmelding wanneer u probeert de toewijzing van de definitie te scheiden.Since there's a relationship between the two items, you'll receive an error when trying to separate the assignment from its definition.

Laten we bijvoorbeeld eens kijken naar een kleine sectie van een hiërarchie voor een besturingselement.For example, let's look at a small section of a hierarchy for a visual.

Diagram van een subset van het voorbeeld van een hiërarchie voor beheergroepen.

Het diagram is gericht op de hoofdbeheergroep met onderliggende IT- en Marketingbeheergroepen.The diagram focuses on the root management group with child I T and Marketing management groups. De IT-beheergroep heeft één onderliggende beheergroep met de naam Productie terwijl de Marketingbeheergroep twee onderliggende abonnementen van de gratis proefversie heeft.The I T management group has a single child management group named Production while the Marketing management group has two Free Trial child subscriptions.

Stel dat er een aangepaste rol is gedefinieerd in de Marketing-beheergroep.Let's say there's a custom role defined on the Marketing management group. Deze aangepaste rol wordt vervolgens toegewezen aan de twee gratis proefabonnementen.That custom role is then assigned on the two free trial subscriptions.

Als we een van deze subabonnementen proberen te verplaatsen naar een onderliggend niveau van de Production-beheergroep, wordt het pad van de abonnementsroltoewijzing naar de roldefinitie van de Marketing-beheergroep verbroken.If we try to move one of those subscriptions to be a child of the Production management group, this move would break the path from subscription role assignment to the Marketing management group role definition. In dit scenario wordt een foutbericht weergegeven waarin staat dat de verplaatsing niet is toegestaan omdat de relatie dan wordt verbroken.In this scenario, you'll receive an error saying the move isn't allowed since it will break this relationship.

Er zijn verschillende opties om dit scenario op te lossen:There are a couple different options to fix this scenario:

  • Verwijder de roltoewijzing uit het abonnement voordat u het abonnement naar een nieuwe bovenliggende beheergroep verplaatst.Remove the role assignment from the subscription before moving the subscription to a new parent MG.
  • Voeg het abonnement toe aan het toewijsbare bereik van de roldefinitie.Add the subscription to the Role Definition's assignable scope.
  • Wijzig het toewijsbare bereik in de roldefinitie.Change the assignable scope within the role definition. In het bovenstaande voorbeeld kunt u de toewijsbare bereiken bijwerken vanuit Marketing naar de hoofdbeheergroep, zodat de definitie kan worden bereikt door beide vertakkingen van de hiërarchie.In the above example, you can update the assignable scopes from Marketing to Root Management Group so that the definition can be reached by both branches of the hierarchy.
  • Maak een andere aangepaste rol die is gedefinieerd in de andere vertakking.Create another Custom Role that is defined in the other branch. Voor deze nieuwe rol moet de roltoewijzing ook worden gewijzigd in het abonnement.This new role requires the role assignment to be changed on the subscription also.

BeperkingenLimitations

Er bestaan beperkingen wanneer u aangepaste rollen gebruikt voor beheergroepen.There are limitations that exist when using custom roles on management groups.

  • U kunt slechts één beheergroep definiëren in het toewijsbare bereik van een nieuwe rol.You can only define one management group in the assignable scopes of a new role. Deze beperking bestaat om het aantal situaties te verminderen waarin de koppeling tussen roldefinities en roltoewijzingen wordt verbroken.This limitation is in place to reduce the number of situations where role definitions and role assignments are disconnected. Deze situatie treedt op wanneer een abonnement of beheergroep met een roltoewijzing wordt verplaatst naar een andere bovenliggende site die niet over de roldefinitie beschikt.This situation happens when a subscription or management group with a role assignment moves to a different parent that doesn't have the role definition.
  • Resourceprovider-gegevensvlakacties kunnen niet worden gedefinieerd in de aangepaste rollen van een beheergroep.Resource provider data plane actions can't be defined in management group custom roles. Deze beperking bestaat omdat er een latentieprobleem is met het bijwerken van de gegevensvlak-resourceproviders.This restriction is in place as there's a latency issue with updating the data plane resource providers. Er wordt aan dit latentieprobleem gewerkt en deze acties worden uitgeschakeld in de roldefinitie om risico's te beperken.This latency issue is being worked on and these actions will be disabled from the role definition to reduce any risks.
  • De Azure Resource Manager valideert niet het bestaan van de beheergroep in het toewijsbare bereik van de roldefinitie.The Azure Resource Manager doesn't validate the management group's existence in the role definition's assignable scope. Als er een type fout of een onjuiste beheer groep-ID wordt vermeld, wordt de roldefinitie nog steeds gemaakt.If there's a typo or an incorrect management group ID listed, the role definition is still created.
  • Roltoewijzing voor een rol met dataActions wordt niet ondersteund.Role assignment for a role with dataActions aren't supported. Maak in plaats daarvan de roltoewijzing in het abonnements bereik.Create the role assignment at the subscription scope instead.

Belangrijk

Het toevoegen van een beheergroep aan AssignableScopes is momenteel in de preview-fase.Adding a management group to AssignableScopes is currently in preview. Deze preview-versie wordt aangeboden zonder service level agreement en wordt niet aanbevolen voor productieworkloads.This preview version is provided without a service level agreement, and it's not recommended for production workloads. Misschien worden bepaalde functies niet ondersteund of zijn de mogelijkheden ervan beperkt.Certain features might not be supported or might have constrained capabilities. Zie Supplemental Terms of Use for Microsoft Azure Previews (Aanvullende gebruiksvoorwaarden voor Microsoft Azure-previews) voor meer informatie.For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Beheergroepen en abonnementen verplaatsenMoving management groups and subscriptions

Als u een beheergroep of een abonnement wilt verplaatsen om het/deze een onderliggend item van een andere beheergroep te maken, moeten drie regels worden geëvalueerd als waar.To move a management group or subscription to be a child of another management group, three rules need to be evaluated as true.

Als u de verplaatsing wilt uitvoeren, hebt u het volgende nodig:If you're doing the move action, you need:

  • Schrijfmachtigingen voor beheergroepen en roltoewijzingen voor het onderliggende abonnement of de beheergroep.Management group write and Role Assignment write permissions on the child subscription or management group.
    • Voor beeld van ingebouwde rol eigenaarBuilt-in role example Owner
  • Schrijftoegang voor de beheergroep op de beoogde bovenliggende beheergroep.Management group write access on the target parent management group.
    • Voorbeeld van een ingebouwde rol: Eigenaar, Inzender, Inzender beheergroepBuilt-in role example: Owner, Contributor, Management Group Contributor
  • Schrijftoegang voor de beheergroep op de bestaande bovenliggende beheergroep.Management group write access on the existing parent management group.
    • Voorbeeld van een ingebouwde rol: Eigenaar, Inzender, Inzender beheergroepBuilt-in role example: Owner, Contributor, Management Group Contributor

Uitzondering: Als de beoogde of bestaande bovenliggende beheergroep de hoofdbeheergroep is, zijn de machtigingsvereisten niet van toepassing.Exception: If the target or the existing parent management group is the Root management group, the permissions requirements don't apply. Omdat de hoofdbeheergroep de standaardplek voor alle nieuwe beheergroepen en abonnementen is, hebt u geen machtigingen nodig om een item te verplaatsen.Since the Root management group is the default landing spot for all new management groups and subscriptions, you don't need permissions on it to move an item.

Als de rol Eigenaar van het abonnement wordt overgenomen van de huidige beheergroep, zijn de verplaatsingsdoelen beperkt.If the Owner role on the subscription is inherited from the current management group, your move targets are limited. U kunt het abonnement alleen verplaatsen naar een andere beheergroep waarvan u de rol Eigenaar hebt.You can only move the subscription to another management group where you have the Owner role. U kunt het niet verplaatsen naar een beheergroep waarvan u een Inzender bent, omdat u dan het eigendom van het abonnement kwijtraakt.You can't move it to a management group where you're a contributor because you would lose ownership of the subscription. Als u direct bent toegewezen aan de rol Eigenaar van het abonnement (niet overgenomen van de beheergroep), kunt u het verplaatsen naar een beheergroep waarvan u een Inzender bent.If you're directly assigned to the Owner role for the subscription (not inherited from the management group), you can move it to any management group where you're a contributor.

Beheergroepen controleren met behulp van activiteitenlogboekenAudit management groups using activity logs

Beheergroepen worden ondersteund door het Azure-activiteitenlogboek.Management groups are supported within Azure Activity Log. U kunt op dezelfde centrale locatie als andere Azure-resources zoeken naar alle gebeurtenissen die in een beheergroep plaatsvinden.You can search all events that happen to a management group in the same central location as other Azure resources. Zo kunt u alle gewijzigde rol- of beleidstoewijzingen binnen een bepaalde beheergroep bekijken.For example, you can see all Role Assignments or Policy Assignment changes made to a particular management group.

Schermopname van activiteitenlogboeken en bewerkingen met betrekking tot de geselecteerde beheergroep.

Bij het uitvoeren van query's op beheergroepen buiten de Azure-portal, ziet het doelbereik voor beheergroepen er als volgt uit: / providers/Microsoft.Management/managementGroups/{yourMgID} .When looking to query on Management Groups outside of the Azure portal, the target scope for management groups looks like "/providers/Microsoft.Management/managementGroups/{yourMgID}".

Volgende stappenNext steps

Voor meer informatie over beheergroepen gaat u naar:To learn more about management groups, see: