[2003] Child domain vs OU voor branch offices*

[Anoniem: 174984]

Hoi,

Ik ben aangewezen een windows 2003 AD tree op te zetten voor het bedrijf waar ik voor werk,
nu ben ik er nog niet uit of ik voor elk van de buitenlandse branch kantoren (7) een apart child domein te gaan maken of voor elk een aparte OU. Of een mix hiervan.

We hebben dus 1 hoofdkantoor en 7 branch kantoren.
2 branch kantoren hebben geen IT afdeling omdat er maar weinig mensen werken. De rest bestaat uit 30 werknemers of meer.

Wie kan mij de voors en tegens uitleggen van Child Domains en OU's? Of zijn er ergens richtlijnen te vinden voor het gebruik van Child Domains of OU's?

Ik heb al een aardig tijdje zitten zoeken naar dit antwoord, maar kan op internet geen helder antwoord vinden.

Alvast bedankt voor de moeite

[Anoniem: 88711]

Oké, heel veel verstand heb ik hier niet van maar dit wil ik je toch echt niet onthouden.
OP de uni van Stansford hebben ze een site die precies hoe en de voors en tegens van, met een wel zeer duidelijke en makkelijk te begrijpen structuur.
Misschien heb je er wat aan!
http://windows.stanford.e...ructure/WinAdminGuide.htm

Welkom op GoT trouwens!

[ Voor 4% gewijzigd door Anoniem: 88711 op 02-05-2006 14:30 . Reden: welkom ]

[Rahvin47]

Ik denk dat je, zeker gezien het feit dat je allerlei branches hebt, je meer zorgen moet maken om het aanmaken van sites en niet zozeer om OU of sub-domein.

Een subdomein zou ik meer doen als je echt die branch min of meer zelfstandige it-support wilt gaan laten doen (decentralisatie).
Maar met 2003 kan je ook prima administratie van een OU delegeren naar een groep.
Beetje meer achtergrond is wel prettig als je het over design aspecten als dit hebt.
Als het hoofdkantoor de enige plek is waar mensen zitten met domain admin rechten zou ik gewoon kiezen voor 1 domein.
maak voor elke lokatie een site aan en zet minimaal 1 DC in elke site en maak deze ook Global Catalog. Zorg voor inter-site verbindingen en let daarbij op dat je gene single point of failure hebt.
Dus niet alleen een siteverbinding van branch naar HQ, maar ook tussen de sites onderling.
Sites met een erg slechte verbinding kan je ook helpen door Universal Group membership cahcing aan te zetten.

Was dit wat je zocht?

[Anoniem: 174984]

@ MACHJE

Heb even de site van Stanford bekeken, zit informatie in die ik goed kan gebruiken.Bedankt.

@RAHVIN47

Er zijn 2 branches die geen IT support hebben, de overige 5 hebben wel hun eigen IT afdeling. Weet niet wat de actuele WIN2003 kennis is bij deze collega's. Op het hoofdkantoor (waar ik zit) is redelijk wat kennis aan boord om dit te kunnen opzetten/beheren.

Alle branches krijgen een eigen DC met de DNS zone van de PDC. Alle grote systemen staan in Nederland, dus de branches gebruiken niet echt veel extra DNS entries. Het gebruik van 1 AD integrated DNS zone zou dus voldoende moeten zijn.

Maar de branches zijn wel zelfstandige ondernemingen, dus politiek gezien zouden ze dan een eigen sub-domein moeten krijgen.

Ben laatst op cursus geweest en de docent zei toen, "Ik zou gewoon allemaal OU's aanmaken, lekker makkelijk te beheren."

Voor de beheerders in de branches is het natuurlijk niet zo leuk een stuk van het werk af te pakken en ze alleen maar rechten te geven op bepaalde delen in Active Directory, waar dan verantwoordelijk voor zijn.

Het management is gebrand op child-domains voor de branches en ik moet ze kunnen overtuigen de mening te veranderen of het met hen eens te zijn.

Ben er dus nog niet helemaal uit, ik ga me nog even verder verdiepen in "sites", kijken wat ik daar wijzer van kan worden.

Bedankt in ieder geval

[Rahvin47]

Sites is puur om je snelheid in je active directory te houden. Dwz zorgen dat je niet van lutjebroek naar tokyo meot connecten om in te kunnen loggen. DNS heeft daar niet zoveel mee te maken.

Zeker gezien je met aparte bedrijfjes te maken krijgt, zou ik voor sub-domeins kiezen.
Hebben ze lekker hun eigen beheer, maar kan jij al enterprise admin toch gewoon overal bij.
Dit heeft vaak erg veel te maken met wat het management wil.
Als die branches ook nog een andere bedrijfsnaam hebben zou ik kiezen voor niet een sub-domein, maar een ander domein in het zelfde forest. Later kan je altijd nog zo'n apart domein opnemen in je corporate domein.

Voorbeeld:

Forest root

Parent.com (DOMEIN) Branch1.com (DOMEIN)

Voordeel heirvan is dat branch1.com zijn eigen naamgeving heeft (ligt vaak HEEL gevoelig bij de medewerkers)

Ander krijg je

Forest root

parent.com

branche1.parent.com

Een combinatie van die 2 kan natuurlijk ook.

[Anoniem: 174984]

Ik denk dat ik de branches zonder IT afdeling zowieso in een OU in het parent (HQ) domein plaats en dan afhankelijk van de kennis en de eventuele bereidheid kennis te verkrijgen de anderen in een sub-domein te plaatsen.

Wat jij al zegt, lekker zelf laten beheren.
Als het fout gaat, kan je altijd nog als enterprise admin ingrijpen.

Volgende week ga ik weer op cursus Win2003 AD infrastructure.
Met deze kennis en de informatie die ik van jullie heb verkregen moet ik wel een goed voorstel aan het management kunnen voorleggen.

In ieder geval bedankt!

PS: betekent niet dat er geen info meer gegeven hoeft te worden door anderen die dit topic bezoeken, hoe meer info hoe beter. :-)

[Rahvin47]

Suc7!

[djluc]

Zijn de bedrijven redelijk hetzelfde of hebben ze allemaal erg verschillende dingen nodig? Ik denk namelijk dat je met 1 domein wel een hoop werk kan besparen. Dat de "lokale" afdelingen daar niet blij mee zijn mag dan even jammer zijn als het wel kosteneffectiever is. Denk bijvoorbeeld aan software deployment e.d. Ik denk dat het een stuk meer moeite kost om dat soort dingen per domein te regelen.

[Question Mark]

Tenzij politieke redenen (zie ook djluc's opmerking over veschillende bedrijven) en/of banbreedte beperking met betrekking tot replicatie geen issue is, adviseert MS altijd voor een single domain forest te gaan. Maakt je beheer ook een stuk eenvoudiger.

Stel nu dat je allemaal domeinen gaat bouwen, je hebt 8 lokaties waarvan je de DC's redundant uit wil voeren. Dit betekent dat je minimaal al 16 DC's nodig bent.

[Yalopa]

Ik zou voor 1 domain gaan met gedelegeerde OU's. Je bespaard jezelf veel werk omdat je veel dingen kan gaan standardiseren, en niet elk departement dezelfde dingen moet gaan doen. Dat gaat je veel werk schelen als je een nieuwe loktie moet gaan opstarten. Uiteindelijk moeten alle sites toch weer gegevens uitwisselen en kan je dan weer met trust relaties aan de slag.


Subdomeinen zijn de NT4 van werken, we zitten nu toch al 2 versies verder. Voor het bandbreedte verbruik zou ik het dus echt niet laten, das allemaal mooi geregeld, of regelbaar...

[ Voor 12% gewijzigd door Yalopa op 04-05-2006 20:19 ]

[alt-92]

Yalopa schreef op donderdag 04 mei 2006 @ 20:18:
Ik zou voor 1 domain gaan met gedelegeerde OU's.

Da's de puur technische blik van $ITer, zonder rekening te houden met gevoelens.
Niet erg hoor, maar dan ga je er wel min of meer vanuit dat IT het doel op zich is, en niet het onderdeel IT van de onderneming als geheel.

Question Mark en djluc verwijzen al naar bedrijfspolitieke redenen om af te wijken van de puur technisch meest makkelijke manier.

[Yalopa]

Aangezien er in de TS geen enkele politieke reden vermeld is zijn er geen. In dat geval raad MS aan om met 1 domein te werken, de politieke redenen zijn voor MS de enige reden om met subdomeinen dan wel met apparte domeinen te werken. Ik ga er helemaal niet van uit dat IT het doel is, maar ik weet uit ervaring dat veel domeinen gewoon niet lekker werken, zeker niet als je users geregeld en tijdelijk in andere vestigingen moeten werken..

En ja ik ben $IT'er, maar als $IT'er in een situatie identiek aan de TS meen ik mijn persoonlijk advies te mogen meedelen, dat is tenslotte hetgeen de TS vraagt.

[alt-92]

Yalopa schreef op donderdag 04 mei 2006 @ 22:35:
Aangezien er in de TS geen enkele politieke reden vermeld is zijn er geen.

Dat weet je niet want dat weet de TS zelf ook nog niet.
Bij een AD design hoor je dat gedeelte ook (al is het maar voor de vorm) voor te leggen.

Bovendien: als je dat vervolgens schriftelijk vastlegt heb je gelijk een warm gevoel van achteren (je kont gedekt).
Immers : $management is ermee akkoord gegaan, dus valt $ITer/designer niet veel meer te verwijten.
Voorkomt lastige RGEs

[djluc]

Het is natuurlijk wel mogelijk om het verhaal een beetje leuker te vertellen voor het management mochten ze die scheiding willen zien. Je meld gewoon dat je "een stricte scheiding" houdt tussen de bedrijven middels het gebruik van OU's en dat dit tevens "een interessante kostenbesparing" met zich mee brengt. Over het algemeen zou dat toch wel voldoende moeten zijn om je zin door te drijven

[paulhekje]

enige reden voor aparte domeinen: -andere password policy is gewenst
de reden voor aparte forest: bedrijven strict kunnen scheiden, zowel qua beheer, beveiliging en om makkelijk te kunnen afstoten.

[Anoniem: 23534]

Yalopa schreef op donderdag 04 mei 2006 @ 22:35:
Aangezien er in de TS geen enkele politieke reden vermeld is zijn er geen. In dat geval raad MS aan om met 1 domein te werken, de politieke redenen zijn voor MS de enige reden om met subdomeinen dan wel met apparte domeinen te werken. Ik ga er helemaal niet van uit dat IT het doel is, maar ik weet uit ervaring dat veel domeinen gewoon niet lekker werken, zeker niet als je users geregeld en tijdelijk in andere vestigingen moeten werken..

En ja ik ben $IT'er, maar als $IT'er in een situatie identiek aan de TS meen ik mijn persoonlijk advies te mogen meedelen, dat is tenslotte hetgeen de TS vraagt.

Je hebt volkomen gelijk; het is veel eenvoudiger qua opzet en flexibeler. Extra domeinen hebben vanuit technisch oogpunt geen toegevoegde waarde.

Verder loop je ook op organisatorisch gebied tegen problemen op als je vestigingen als aparte domeinen gaat opzetten. Wat nu als een bepaald organisatieonderdeel dwars door al die vestigingen heen vertegenwoordigd is? En wat als de organisatiestructuur verandert in de nabije toekomst? OU's zijn zoveel flexibeler dan domeinen dat je daar wel mee overweg kan.

Wat je verder terecht aangeeft is dat je het lastiger maakt om als gebruiker tussen vestigingen te zwerven.

[Grolsch]

MS zegt zelf dat je altijd OU's moet gebruiken, tenzei je een hele goede reden hebt om meerdere domeinen te gebruiken. Het delegeren van beheer is hier geen reden voor, want dat kun je met OU's ook wel.

Een goede reden kan zijn, verschillende namen (FQDN), of een verschillende password policy.

[Anoniem: 174645]

Een goede reden kan zijn, verschillende namen (FQDN), of een verschillende password policy.

Je kunt gewoon 1 domein aanhouden scheelt een hoop werk en als ze alle bedrijfsnamen of organisaties willen terug laten komen in bv gebruikers login maak dan voor iedere tak die dat zo graag wil een UPN (User Principal Name) aan. Je krijgt dan als gebruikers login Bijv. [e-mail] en de ander [e-mail]. Dan zijn de managers blij want het is veel minder beheers werk met de OU’s kun je beheerstaken uit handen geven aan de locale afdelingen. en Als je wilt kan je ze ook beheer geven over een deel van hun servers.

Waar je dit kunt vinden? ...Domains and trusts rechts klik in de MMC ...Domains and trusts op ...Domains and trusts

Wij hebben bijv. voor in Amerika een aparte tak die het beheer daar doen en in Canada maar als er wat met de DC's moet gebeuren dan doen we dat samen met hun. In Azië idem twee locaties support van uit 1 locatie. Hebben zij het idee dat ze ook nog wat mogen en hier op het hoofd kantoor houden we de controle over de hele toko. Als je met childs gaat werken zou ik dat eerder doen om bedrijfskritische onderdelen in een top level domain te stoppen en de rest er onder (scheiding resources en users) maar wel alle users in 1 domein. Als je dan de toplevel hebt ingericht hoef je hier bijna nooit wat te doen blijft lekker stabiel doordraaien. In het gedeelte waar alle gebruikers zitten word het meeste gedaan de kans dat een foutje in dat deel dan je resources als exchange en dergelijke plat leggen is erg klein.

Als het even kan hou het dan zo simpel mogelijk!