Uw resources organiseren met Azure-beheergroepenOrganize your resources with 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.

Voorbeeld van een hiërarchiestructuur voor beheergroepen

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 (EA)-abonnementen die afgeleide zijn van die beheer groep 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 in de beheergroep één toewijzing voor op rollen gebaseerd toegangsbeheer (RBAC) maken, die de toegang doorgeeft aan alle abonnementen.By moving multiple subscriptions under that management group, you can create one role-based access control (RBAC) 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 RBAC-toewijzingen in meerdere abonnementen.One assignment on the management group can enable users to have access to everything they need instead of scripting 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 RBAC-toewijzingen op directoryniveau toepassen.This root management group allows for global policies and RBAC 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 RBAC-rol toewijzen aan andere directory-gebruikers of -groepen om de hiërarchie te beheren.After elevating access, the administrator can assign any RBAC 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 de naam van een beheer groep wijzigen om de naam van een beheer groep 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 RBAC-rol toewijzen aan andere gebruikers, zodat deze het beheer daarover hebben.Once they have access to the root management group, the global administrators can assign any RBAC role to other users to manage it.

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) hebben.User 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.

  1. Alle rol- en beleidstoewijzingen uit de hoofdbeheergroep verwijderenRemove all Role and Policy assignments from the root management group
    1. 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 will backfill 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.
    2. 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.
  2. De API rechtstreeks aanroepen om het backfill-proces te startenCall the API directly to start the backfill process
    1. 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 (RBAC) van Azure voor alle soorten toegang tot resources en roldefinities.Azure management groups support Azure Role-Based Access Control (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. Een RBAC-rol kan worden toegewezen aan een beheer groep die de hiërarchie naar de resources overneemt.Any RBAC role can be assigned to a management group that will inherit down the hierarchy to the resources. Zo kan de RBAC-rol van VM-inzender aan een beheergroep worden toegewezen.For example, the RBAC 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 RBAC-rolRBAC 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.
* *: Roltoewijzingen voor de hoofd beheer groep zijn niet vereist voor het verplaatsen van een abonnement of beheer groep naar en van het item.**: 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 definitie en toewijzing van de RBAC-rolCustom RBAC role definition and assignment

Aangepaste RBAC-functie ondersteuning voor beheer groepen is momenteel in Preview met enkele beperkingen.Custom RBAC 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 RBAC-rol is dan beschikbaar voor toewijzing in die beheergroep en alle beheergroepen, abonnementen, resourcegroepen en resources daaronder.That custom RBAC 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.

Voorbeeld definitieExample definition

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

Gebruik de ID van de beheer groep en niet de weergave naam van de beheer groep.Use the management group's ID and not the management group's display name. Deze algemene fout treedt op omdat beide aangepaste gedefinieerde velden zijn bij het maken van een beheer groep.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 pad van de toewijzings hiërarchieIssues with breaking the role definition and assignment hierarchy path

Roldefinities kunnen overal binnen de hiërarchie van de beheer groep worden toegewezen.Role definitions are assignable scope anywhere within the management group hierarchy. Een roldefinitie kan worden gedefinieerd voor een bovenliggende beheer groep terwijl de daad werkelijke 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 tussen de twee items bestaat, wordt er een fout bericht weer gegeven wanneer u probeert de toewijzing te scheiden van de definitie.Since there is a relationship between the two items, you will receive an error when trying to separate the assignment from its definition.

Bijvoorbeeld: we kijken naar een kleine sectie van een hiërarchie voor een visueel element.For example: Let's look at a small section of a hierarchy for a visual.

onderliggende boom structuur

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

Als we een van deze abonnementen proberen te verplaatsen naar een onderliggend niveau van de productie beheer groep, verbreekt deze verplaatsing het pad van de toewijzing van de abonnements functie naar de functie definitie van de marketing beheer groep.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 fout bericht weer gegeven waarin wordt aangegeven dat de verplaatsing niet is toegestaan omdat deze relatie 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 verplaatst naar een nieuwe bovenliggende MG.Remove the role assignment from the subscription prior to moving the subscription to a new parent MG.
  • Voeg het abonnement toe aan het toewijs bare bereik van de functie definitie.Add the subscription to the Role Definition's assignable scope.
  • Wijzig het toewijs bare bereik in de roldefinitie.Change the assignable scope within the role definition. In het bovenstaande voor beeld kunt u de toewijs bare bereiken bijwerken vanuit marketing naar de hoofd beheer groep, 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 extra aangepaste rol die wordt gedefinieerd in de andere vertakking.Create an additional Custom Role that will be defined in the other branch. Deze nieuwe rol vereist ook dat de roltoewijzing voor het abonnement wordt gewijzigd.This new role will require the role assignment to be changed on the subscription also.

BeperkingenLimitations

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

  • U kunt slechts één beheer groep definiëren in het toewijs bare bereik van een nieuwe rol.You can only define one management group in the assignable scopes of a new role. Deze beperking is van kracht om het aantal situaties te verminderen waarin functie definities en roltoewijzingen worden losgekoppeld.This limitation is in place to reduce the number of situations where role definitions and role assignments are disconnected. Dit gebeurt wanneer een abonnement of beheer groep met een roltoewijzing wordt verplaatst naar een andere bovenliggende site die niet over de roldefinitie beschikt.This happens when a subscription or management group with a role assignment is moved to a different parent that doesn't have the role definition.
  • RBAC-gegevens vlak acties mogen niet worden gedefinieerd in aangepaste rollen van de beheer groep.RBAC Data Plane actions aren't allowed to be defined in management group custom roles. Deze beperking is van kracht omdat er een latentie probleem is met RBAC-acties bij het bijwerken van de gegevens vlak resource providers.This restriction is in place as there is a latency issue with RBAC actions updating the data plane resource providers. Er wordt met dit latentie probleem gewerkt en deze acties worden uitgeschakeld uit de roldefinitie om Risico's te verminderen.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 beheer groep in het toewijs bare 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-of onjuiste beheer groep-ID wordt weer gegeven, wordt de roldefinitie nog steeds gemaakt.If there is a typo or a incorrect management group ID listed, the role definition will still be created.

Beheer groepen en abonnementen verplaatsenMoving management groups and subscriptions

Als een beheer groep of een abonnement een onderliggend item van een andere beheer groep is, moeten drie regels worden geëvalueerd als waar.To a management group or subscription to be a child of another management group, three rules need to be evaluated as true.

Als u de verplaatsings actie uitvoert, hebt u het volgende nodig:If you're doing the move action, you need:

  • Schrijf machtigingen voor schrijven en rollen toewijzen aan de beheer groep voor het onderliggende abonnement of de beheer groep.Management group write and Role Assignment write permissions on the child subscription or management group.
    • Voor beeld eigenaar van ingebouwde rolBuilt-on role example Owner
  • Schrijf toegang van de beheer groep op de bovenliggende doel beheer groep.Management group write access on the target parent management group.
    • Voor beeld van ingebouwde rol: eigenaar, Inzender, Inzender voor beheer groepenBuilt-in role example: Owner, Contributor, Management Group Contributor
  • Schrijf toegang van de beheer groep voor de bestaande bovenliggende beheer groep.Management group write access on the existing parent management group.
    • Voor beeld van ingebouwde rol: eigenaar, Inzender, Inzender voor beheer groepenBuilt-in role example: Owner, Contributor, Management Group Contributor

Uitzonde ring: als het doel of de bestaande bovenliggende beheer groep de hoofd beheer groep is, zijn de machtigingen vereisten 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 hoofd beheer groep de standaard overgangs plaats voor alle nieuwe beheer groepen 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 van eigenaar van het abonnement wordt overgenomen van de huidige beheer groep, zijn de verplaatsings doelen 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 beheer groep waar 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 beheer groep waar u mede werker bent, omdat u de eigenaar 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 wordt toegewezen aan de rol van eigenaar van het abonnement (niet overgenomen van de beheer groep), kunt u deze verplaatsen naar een beheer groep waar u een bijdrager 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.

Activiteitenlogboeken met beheergroepen

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: