Een van de meest gestelde vragen bij het inrichten van Google Workspace is wanneer je een organizational unit gebruikt en wanneer een Google Group. Ze lijken oppervlakkig op elkaar, want beide bundelen gebruikers, maar ze lossen totaal verschillende problemen op. Wie ze door elkaar haalt, krijgt rommelig beheer en onverwacht gedrag.
Het kernverschil
Het verschil is in één zin te vatten: OU's bepalen wat een gebruiker mag, Groups bepalen met wie iets wordt gedeeld. Een OU is een beleidscontainer. Plaats je een gebruiker in een OU, dan gelden de instellingen van die OU voor hem: welke services aanstaan, welk Gmail-routingbeleid geldt, welke beveiligingsregels van toepassing zijn.
Een Group is een verzendlijst en een toegangsbundel. Stuur je een mail naar het groepsadres, dan ontvangen alle leden hem. Deel je een document met de groep, dan krijgen alle leden toegang. Een gebruiker kan lid zijn van veel groepen tegelijk, maar hoort altijd bij precies één OU.
Eén OU, vele Groups
Onthoud deze regel: een gebruiker zit in exact één organizational unit, maar kan lid zijn van talloze Google Groups. Dat verschil verklaart meteen waarvoor je elk instrument inzet. Overlappende lidmaatschappen horen bij Groups, exclusieve beleidstoewijzing hoort bij OU's.
Wanneer kies je een OU
Kies een OU als je instellingen wilt differentiëren tussen groepen gebruikers. Een paar concrete situaties:
- Stagiairs mogen geen e-mail naar externe ontvangers sturen.
- De financiële afdeling moet verplicht tweestapsverificatie gebruiken.
- Een bepaalde afdeling krijgt geen toegang tot YouTube binnen Workspace.
- Een testgroep mag als eerste nieuwe functies uitproberen.
In al deze gevallen gaat het om beleid dat per groep verschilt. Dat regel je via OU's.
Wanneer kies je een Group
Kies een Group als je communicatie of gedeelde toegang wilt regelen. Voorbeelden:
- Een mailadres zoals support@bedrijf.nl dat een heel team bereikt.
- Toegang geven tot een gedeelde Drive aan een projectteam.
- Een agenda delen met een afdeling.
- Toegang tot een specifieke applicatie regelen op basis van groepslidmaatschap.
Groepen kunnen ook beleid dragen
In de Admin Console kun je sommige service-instellingen ook op basis van groepslidmaatschap toepassen, niet alleen op OU-niveau. Google noemt dit configuratiegroepen (voor service-instellingen) en toegangsgroepen (voor het aan- of uitzetten van een service). Dat is handig wanneer een beleidsregel niet netjes samenvalt met je OU-structuur. Toch blijft de basis: structurele, exclusieve beleidstoewijzing via OU's, overlappende of dynamische toewijzing via Groups.
Ze werken samen
In de praktijk gebruik je beide naast elkaar. Een typische inrichting ziet er zo uit: je OU-structuur volgt de plekken waar beleid echt verschilt, en daarnaast heb je een set Groups voor teams, projecten en mailinglijsten die dwars door je OU-structuur heen lopen.
Giet niet je hele organogram in OU's
Probeer niet je hele organogram in OU's te gieten. Een OU die geen afwijkend beleid heeft, voegt niets toe en maakt het beheer alleen complexer. Maak een OU pas aan als er een concrete beleidsbehoefte is, en gebruik Groups voor alle samenwerkings- en communicatiebehoeften.
Een praktisch beslismodel
Stel jezelf bij twijfel deze vraag: gaat het om een instelling of service die voor deze mensen anders moet zijn dan voor de rest? Dan is het een OU. Gaat het erom dat deze mensen samen iets ontvangen of ergens toegang toe krijgen? Dan is het een Group. Die ene vraag lost de meeste twijfelgevallen meteen op.
Zo bepaal je per geval OU of Group
- Schrijf op wat je precies wilt bereiken in één zin.
- Bevat die zin een instelling, service of beveiligingsregel die anders moet zijn? Dan hoort het bij een OU.
- Gaat het over samen e-mail ontvangen, delen of toegang krijgen? Dan hoort het bij een Group.
- Verschilt het beleid voor een kleine groep mensen dwars door je OU-structuur heen? Gebruik dan een configuratiegroep of toegangsgroep in plaats van een nieuwe OU.
- Controleer na het instellen het effect bij één testgebruiker voordat je het breed uitrolt.
Kan ik beleid toepassen op een Google Group?
Voor een aantal instellingen wel. Google ondersteunt groepsgebaseerde toewijzing via configuratiegroepen voor service-instellingen en via toegangsgroepen voor het aan- of uitzetten van een service. Niet elke instelling is op groepsniveau beschikbaar, dus structureel beleid blijft het sterkst via OU's.
Kan een gebruiker in meerdere OU's zitten?
Nee. Elke gebruiker hoort bij precies één OU. Voor overlappende toewijzing gebruik je Groups, want daar kan een gebruiker onbeperkt lid van zijn.
Vervangt een Group ooit een OU?
Nee, ze vullen elkaar aan. Een Group regelt communicatie en delen, een OU regelt beleid en services. Je hebt vrijwel altijd beide nodig.
Wat gebeurt er als beleid op OU en Group botst?
Bij service-instellingen via configuratiegroepen geldt: de instelling van de groep overschrijft de instelling van de OU. Zit een gebruiker in meerdere groepen met conflicterende waarden, dan bepaalt de prioriteitsvolgorde van die groepen welke wint. Controleer het resultaat altijd per instelling bij een testgebruiker.
Hoeveel OU-niveaus kan ik aanmaken?
Je kunt een diepe boomstructuur van child-OU's opbouwen, waarbij child-OU's instellingen erven van hun bovenliggende OU. Houd de structuur in de praktijk zo plat mogelijk, want elk niveau zonder afwijkend beleid maakt het beheer onnodig ingewikkeld.
Werkt een gedeelde Drive met een OU of met een Group?
Toegang tot een gedeelde Drive regel je via Groups, niet via OU's. Voeg het projectteam toe als groepslid en geef de groep toegang, zodat nieuwe teamleden automatisch toegang krijgen zodra je ze aan de groep toevoegt.