Active Directory implementatie vraagje.

[ActualF06]

Ik heb een korte vraag, waar ik wel een vermoeden heb van het antwoord, maar toch niet helemaal zeker van ben.

Wij hebben twee locaties. Ik wil deze locaties met elkaar verbinden en beide onderbrengen in een AD domein structuur. Het gaat om het hoofdkantoor, en om een rack in een datacentrum.

Mijn gedachte was dus om een site-to-site VPN op te zetten tussen de twee locaties, en dan gewoon twee domeinen te maken.

Hoofdkantoor.bedrijf.local
Datacentrum.bedrijf.local

Nu komt het probleem, waar ik vrees dat ik een extra machine voor nodig heb. Ik zou graag het hoofddomein bedrijfsnaam.local laten zijn. Maar dat betekend dan dus dat dat een aparte machine is, en dat voor beide domeinen, ik dus ook nog een machine als DC moet hebben. Of vergis ik me daar dan in ?

Het mooiste zou zijn,

bedrijfsnaam.local met op dezelfde machine hoofdkantoor.bedrijfsnaam.local, en in het datacentrum datacentrum.bedrijfsnaam.local.

Klopt mijn gedachte dat ik voor deze setup tenminste 3 machines nodig heb, ervanuitgaande dat ik op alle locaties een DC wil hebben.

[mgizmo]

Als je het over AD domeinen hebt heb je inderdaad 3 DC's nodig. Wellicht is virtualisatie een optie voor je.

[ActualF06]

mgizmo schreef op maandag 01 november 2010 @ 13:26:
Als je het over AD domeinen hebt heb je inderdaad 3 DC's nodig. Wellicht is virtualisatie een optie voor je.

Virtualisatie is dan idd een optie.

Het lijkt me nl, dat de server die het bedrijfsnaam.local domein beheerd voor de rest niks staat te doen in deze situatie. Dat zou een beetje zonde zijn.

[tc982]

Virtualiseren is goed, maar ik raad je ten sterkste af om de AD enkel virtueel te draaien. Zet ergens een pc waar je Windows Server ( 200x ) op zet en maak deze mee domain controller... Beetje meer full-proof...

[ActualF06]

Ik denk dat we dan maar voor de andere optie gaan trouwens.

Gewoon 1 forest, met daarin bedrijfsnaam.local. Dit is dan op het hoofdkantoor, en dan het datacentrum een child domein, onder dit hoofddomein. Dat doet ook wat we willen. dc.bedrijfsnaam.local.

[Zwelgje]

tc982 schreef op maandag 01 november 2010 @ 13:32:
Virtualiseren is goed, maar ik raad je ten sterkste af om de AD enkel virtueel te draaien. Zet ergens een pc waar je Windows Server ( 200x ) op zet en maak deze mee domain controller... Beetje meer full-proof...

waarom wat is er niet full proof aan een VM omgeving bang dat de hypervisor niet meer werkt en dat er niemand meer kan inloggen ...lekker zinvol als je wel kan authenticeren maar vervolgens exchange/sql/crm/%enterpriseapp% niet meer werkt omdat het virtueel draait

mgoed mischien zie ik het wel verkeerd, dan laat ik me graag corrigeren

[_Arthur]

ActualF06 schreef op maandag 01 november 2010 @ 13:47:
Gewoon 1 forest, met daarin bedrijfsnaam.local. Dit is dan op het hoofdkantoor, en dan het datacentrum een child domein, onder dit hoofddomein. Dat doet ook wat we willen. dc.bedrijfsnaam.local.

Ook nog een bepaalde reden om een child domein te maken?

[ActualF06]

_Arthur schreef op maandag 01 november 2010 @ 14:15:
[...]

Ook nog een bepaalde reden om een child domein te maken?

Ik heb het liefst zo eenvoudig mogelijk beheer tussen de twee domeinen. De developers zijn constant bezig met het aanpassen van onze IIS servers in de webfarm, er wordt cosntant data gekopieerd, dus lijkt het mij de eenvoudgiste manier, met het minst mogelijke beheer voor alle rechten.

Maar, mijn kennis gaat niet ver genoeg om nu zo te zeggen, dit is DE oplossing.

[mbaltus]

tc982 schreef op maandag 01 november 2010 @ 13:32:
Zet ergens een pc waar je Windows Server ( 200x ) op zet en maak deze mee domain controller... Beetje meer full-proof...

Dat lijkt me juist meer afbreuk doen aan een stabiele omgeving! Zet dan op z'n minst een server in. Als performance geen issue is (omdat de server weinig te doen heeft) kun je gaan voor een instapserver. Maar een PC.....

Ik zou ook zeker niet zomaar Child Domains maken. Wat is de toegevoegde waarde of wat probeer je hiermee te bereiken? AD kan prima met verschillende Sites overweg.
Door van deze structuur gebruik te maken, maak je het alleen maar moeilijker voor jezelf. Extra servers te onderhouden, een lastigere AD structuur, meer servers (is één DC op hoofdniveau wel voldoende of moet je van alles meerdere DC's gaan laten draaien).
Wat in ieder geval niet kan is om twee AD domeinen te hosten op één DC.

edit:
Toevoeging:

ActualF06 schreef op maandag 01 november 2010 @ 14:20:
Ik heb het liefst zo eenvoudig mogelijk beheer tussen de twee domeinen. De developers zijn constant bezig met het aanpassen van onze IIS servers in de webfarm, er wordt cosntant data gekopieerd, dus lijkt het mij de eenvoudgiste manier, met het minst mogelijke beheer voor alle rechten.

Als dat de reden is, zou ik ze eerder local admin op die betreffende servers maken (wel netjes met groepen werken natuurlijk en niet individuele gebruikers lid maken!)

[Voor 23% gewijzigd door mbaltus op 01-11-2010 15:49]

[ActualF06]

mbaltus schreef op maandag 01 november 2010 @ 15:48:
[...]

Dat lijkt me juist meer afbreuk doen aan een stabiele omgeving! Zet dan op z'n minst een server in. Als performance geen issue is (omdat de server weinig te doen heeft) kun je gaan voor een instapserver. Maar een PC.....

Ik zou ook zeker niet zomaar Child Domains maken. Wat is de toegevoegde waarde of wat probeer je hiermee te bereiken? AD kan prima met verschillende Sites overweg.
Door van deze structuur gebruik te maken, maak je het alleen maar moeilijker voor jezelf. Extra servers te onderhouden, een lastigere AD structuur, meer servers (is één DC op hoofdniveau wel voldoende of moet je van alles meerdere DC's gaan laten draaien).
Wat in ieder geval niet kan is om twee AD domeinen te hosten op één DC.

edit:
Toevoeging:

[...]

Als dat de reden is, zou ik ze eerder local admin op die betreffende servers maken (wel netjes met groepen werken natuurlijk en niet individuele gebruikers lid maken!)

Dankje voor je uitleg.

Er zijn eigenlijk geen fysieke gebruikers in het datacentrum. We hosten daarvandaan alleen de websites/shops van onze klanten. Er wordt wat geFTP'd daarheen, en er draaien een 6 tal servers die onderling wel met elkaar moeten kunnen praten, en dat nu nog in een workgroup doen. Helaas lopen we dan tegen nare dingen aan met php authorisaties en iusr gebruikers van de diverse webservers.

Daar wilde ik dus eigenlijk een domein voor maken. Ik zal me eens in die sites gaan verdiepen.

Ik moet eerlijk zeggen dat ik dit soort dingen wel vaker heb met MS producten. Er zijn zoveel wegen naar Rome En geen enkele is de "beste" of "juiste". Dit met die domeinen kan je weer op 10tallen manieren oplossen. Het maakt je aan het twijfelen of je wel de juiste keuze maakt.

[Voor 8% gewijzigd door ActualF06 op 01-11-2010 16:26]

[mbaltus]

ActualF06 schreef op maandag 01 november 2010 @ 16:21:
Ik moet eerlijk zeggen dat ik dit soort dingen wel vaker heb met MS producten. Er zijn zoveel wegen naar Rome En geen enkele is de "beste" of "juiste". Dit met die domeinen kan je weer op 10tallen manieren oplossen. Het maakt je aan het twijfelen of je wel de juiste keuze maakt.

De juiste keuze is er misschien niet eens..... In ieder geval moet je op zoek naar de juiste keuze voor jouw situatie.

Wat ik me wel nog voor kan stellen is dat je een Forest maakt. Dan heb je twee AD-domeinen (met onderlinge trusts). Het voordeel is dat je een betere scheiding van rechten/security kunt inregelen. Als de servers in het Datacenter alleen apps, etc. van klanten gehost worden, lijkt me dat een cleanere aanpak. Verder heb je dan geen root-DC nodig.

[Zwelgje]

mbaltus schreef op maandag 01 november 2010 @ 16:45:
[...]

De juiste keuze is er misschien niet eens..... In ieder geval moet je op zoek naar de juiste keuze voor jouw situatie.

Wat ik me wel nog voor kan stellen is dat je een Forest maakt. Dan heb je twee AD-domeinen (met onderlinge trusts). Het voordeel is dat je een betere scheiding van rechten/security kunt inregelen. Als de servers in het Datacenter alleen apps, etc. van klanten gehost worden, lijkt me dat een cleanere aanpak. Verder heb je dan geen root-DC nodig.

pff ik zou gewoon 1 Domain aanhouden (KISS principe) en dan die servers in een aparte OU (duh ) met een 'delegation of control' ingesteld om beheer te verdelen.

_{KISS=Keep It Simple Stupid}

my 2 cents

[mbaltus]

Enerzijds eens met de eenvoud, maar aangezien het om hosting voor klanten gaat kan ik me ook voorstellen dat je een fijnere controle over rechten wilt hebben. Zijn beheerders (domain admins) van je KA ook beheerders van je klantomgeving?

[Jazzy]

Powershell schreef op maandag 01 november 2010 @ 16:48:
[...]


pff ik zou gewoon 1 Domain aanhouden (KISS principe) en dan die servers in een aparte OU (duh ) met een 'delegation of control' ingesteld om beheer te verdelen.

_{KISS=Keep It Simple Stupid}

my 2 cents

Daar sluit ik me bij aan. Bovendien is het voor een skilled administrator een fluitje van een cent om zich beheerdersrechten toe te eigenen in het root-domein.

Maar al in je startpost had ik het idee dat je niet helemaal kunt overzien wat je aan het doen bent. is het een idee om eens een consultant over de vloer te halen om je visie tegen iemand met kennis aan te houden?

[tc982]

Powershell schreef op maandag 01 november 2010 @ 14:09:
[...]


waarom wat is er niet full proof aan een VM omgeving bang dat de hypervisor niet meer werkt en dat er niemand meer kan inloggen ...lekker zinvol als je wel kan authenticeren maar vervolgens exchange/sql/crm/%enterpriseapp% niet meer werkt omdat het virtueel draait

mgoed mischien zie ik het wel verkeerd, dan laat ik me graag corrigeren

Goed en wel, maar een DC is meestal ook DNS, en je zal niet de eerste zijn die niet meer kan aanmelden op hun System Center omdat hun DC die virtueel is, down ligt. Ik zal er altijd voor zorgen dat ik minstens een managment server heb die ik ook DC kan maken. Meestal een low cost server ( DL180 ). Je lacht er misschien mee, maar ik heb het toch al een paar keer zo gezien dat het fout ging bij andere. Mij gaan ze hier niet mee hebben.

[Voor 29% gewijzigd door tc982 op 01-11-2010 18:09]

[Mike2k]

tc982 schreef op maandag 01 november 2010 @ 18:07:
[...]


Goed en wel, maar een DC is meestal ook DNS, en je zal niet de eerste zijn die niet meer kan aanmelden op hun System Center omdat hun DC die virtueel is, down ligt. Ik zal er altijd voor zorgen dat ik minstens een managment server heb die ik ook DC kan maken. Meestal een low cost server ( DL180 ). Je lacht er misschien mee, maar ik heb het toch al een paar keer zo gezien dat het fout ging bij andere. Mij gaan ze hier niet mee hebben.

Ja uhh, daarom heeft de TS toch op beide locaties een DC draaien met een site-to-site VPN...?

[Jazzy]

tc982 schreef op maandag 01 november 2010 @ 18:07:
[...]


Goed en wel, maar een DC is meestal ook DNS, en je zal niet de eerste zijn die niet meer kan aanmelden op hun System Center omdat hun DC die virtueel is, down ligt. Ik zal er altijd voor zorgen dat ik minstens een managment server heb die ik ook DC kan maken. Meestal een low cost server ( DL180 ). Je lacht er misschien mee, maar ik heb het toch al een paar keer zo gezien dat het fout ging bij andere. Mij gaan ze hier niet mee hebben.

Kom op zeg, dan log je toch gewoon in op de hypervisor zelf? Daar heb je geen Virtual Center of SCVMM voor nodig hoor.

[alt-92]

ActualF06 schreef op maandag 01 november 2010 @ 14:20:
[...]


Ik heb het liefst zo eenvoudig mogelijk beheer tussen de twee domeinen.

Dan hou je het juist bij één domain en gebruik je sites.

Of je moet met alle geweld een security boundary willen creeren met twee domains, maar dan nog zul je ergens je forest + root op moeten hosten.

[wasted247]

Toevallig hier laatst ook in verdiept, hierbij wat interessant leesvoer. Wij draaien 1 forrest met daarin 1 domein, met hierin diverse sites voor routering en ou's voor delegatie. Onze opzet lijkt ook hetzelfde, kantooromgeving en een datacenter met daarin een hoop webservers en andere diensten.

Wat betreft virtuele domein controllers, prima te doen. Wij draaien zowel op kantoor als in het datacenter alle DC's virtueel. Het enige wat potentieel een probleem zou kunnen opleveren is dat virtuele klok tikken minder accuraat zijn en AD nogal tijds afhankelijk is. Zie dit artikel van VMware, hier ook wat andere opmerkingen van Microsoft. Het is mij iig altijd aangegeven als reden om DC's niet virtueel te draaien. Echter heb ik er zelf op meerdere lokaties / omgevingen nooit problemen mee ondervonden.

Betreft de redundantie van je virtuele DC's, dat is een kwestie van goed plannen, redundant netwerk, storage, hosts, en een regel in je VM omgeving dat de DC's niet op dezelfde host mogen staan moet genoeg zijn.

[Voor 15% gewijzigd door wasted247 op 01-11-2010 21:49]

[Jazzy]

wasted247 schreef op maandag 01 november 2010 @ 20:03:
Wat betreft virtuele domein controllers, prima te doen. Wij draaien zowel op kantoor als in het datacenter alle DC's virtueel. Het enige wat potentieel een probleem zou kunnen opleveren is dat virtuele klok tikken minder accuraat zijn en AD nogal tijds afhankelijk is. Zie dit artikel van VMware, hier ook wat opmerkingen van Microsoft. Ik heb er echter nooit wat van gemerkt, maar het is mij iig altijd aangegeven als reden om DC's niet virtueel te draaien.

Best practice is om gevirtualiseede domain controllers ofwel vaker te laten synchroniseren met de PDC Emulator ofwel te synchroniseren tegen iets anders (hypervisor host of een ntp server). Ik zie niet in waarom je domain controllers niet zou virtualiseren terwijl je het issue met tijd makkelijk op kunt lossen.

[wasted247]

Jazzy schreef op maandag 01 november 2010 @ 20:12:
Ik zie niet in waarom je domain controllers niet zou virtualiseren terwijl je het issue met tijd makkelijk op kunt lossen.

That's my point, in mijn ervaring kun je domain controllers prima virtualiseren.

Jazzy schreef op maandag 01 november 2010 @ 20:24:
Sorry, ik had je laatste zin niet goed begrepen.

Np, het stond er ook een beetje scheef. There, i fixed it

[Voor 30% gewijzigd door wasted247 op 01-11-2010 21:49]

[Jazzy]

Sorry, ik had je laatste zin niet goed begrepen.

[Razwer]

tc982 schreef op maandag 01 november 2010 @ 18:07:
[...]


Goed en wel, maar een DC is meestal ook DNS, en je zal niet de eerste zijn die niet meer kan aanmelden op hun System Center omdat hun DC die virtueel is, down ligt. Ik zal er altijd voor zorgen dat ik minstens een managment server heb die ik ook DC kan maken. Meestal een low cost server ( DL180 ). Je lacht er misschien mee, maar ik heb het toch al een paar keer zo gezien dat het fout ging bij andere. Mij gaan ze hier niet mee hebben.

HAHAHAHA sorry kon het niet laten om hier niet op te reageren. Wat voor prutsers ga je mee om dat die spullen op zn gat liggen?

voor de rest, i'm with ALT92, Powershell, Jazzy en wasted... niets aan toe te voegen. single domain, lekker virtualiseren.

[mgizmo]

Als je DC's niet wilt virtualiseren, omdat je hoofdreden zou zijn dat een DC altijd alive moet zijn, dan heb je zelf geen vertrouwen in je gevirtualiseerde omgeving. Touche als je geen redudancy onderhoudt of geen HA tot je beschikking hebt, maar dan nog. Een gevirtualiseerde server is sneller op te brengen dan een fysieke.
Echt als je bang bent voor down time van hypervisors, vertrouw je je eigen omgeving ook niet. Dan schoort het niet aan de hypervisors maar aan de inrichting of mensenlijke factor.

[ActualF06]

Bedankt voor alle tips.

Ik ga er mee aan de slag, enh et eens op papier uitwerken, met 1 domein gescheiden door 2 sites.

[mgizmo]

AD vergt wel meer kennis dan dat je nu laat blijken. In workgroups ben je aardig contained, maar met een AD....

[ActualF06]

We draaien al heel lang met AD in een SBS omgeveing, het heeft niet zo zeer met kennis te maken. Zeker de basis AD is vrij eenvoudig. Het probleem zat hem er meer in dat er zo veel mogelijkheden zijn, en ik gewoon op zoek ben naar voor ons de beste.

De Microsoft manier zou met child domeinen werken in deze situatie, zeker de boeken over Windows server 2008, en AD gaan uit van die structuur. Vandaar dat ik daar mee kwam als eerste.

[Jazzy]

ActualF06 schreef op woensdag 03 november 2010 @ 11:07:
Bedankt voor alle tips.

Ik ga er mee aan de slag, enh et eens op papier uitwerken, met 1 domein gescheiden door 2 sites.

Even checken, maar wat is volgens jou precies de reden om twee sites aan te maken?

[ActualF06]

Zitten we hier op een examen of zo ?

De verbinding tussen de twee vestigingen is een "trage" en "onbetrouwbare" dsl verbinding, plus de webservers in het datacentrum maken gebruik van een fileserver aan die kant waardoor er snel aangemeld moet kunnen worden. Het lijkt me dus verstandig om de tweede DC dezelfde functies te geven als de eerste DC, om zo onafhankelijk te zijn in geval van problemen met de lijn.

Ben ik geslaagd ?

[Jazzy]

Zodat replicatieverkeer niet over de lijn gaat dus. Prima, geslaagd.

Reden dat ik het vroeg ik dat ik niet zeker wist of het kwartje is gevallen. Je zegt verbvolgens namelijk:

De Microsoft manier zou met child domeinen werken in deze situatie, zeker de boeken over Windows server 2008, en AD gaan uit van die structuur. Vandaar dat ik daar mee kwam als eerste.

Er is niet zoiets als 'de Microsoft manier'. Je moet eerst je requirements helder hebben en dan een passende oplossing kiezen. Microsoft zal nooit een child domain adviseren als je slechts replicatieverkeer wilt verminderen tussen sites.

[_Arthur]

ActualF06 schreef op woensdag 03 november 2010 @ 11:28:
Zitten we hier op een examen of zo ?

Je moet het anders zien. Door tegen vragen te stellen hopen we dat jezelf tot meer inzicht komt zonder dat 'wij' jou een antwoord voorkauwen.

Hierdoor ontwikkel je zelf je kennis en kan je dus uiteindelijk tot een goed besluit komen.

[mgizmo]

En hoe gaat het plaatje er uit zien? Wellicht dat we daar nog haken en ogen kunnen aanwijzen, for free.

[Razwer]

nog een leuke trouwens, default bij het opzetten van een nieuwe site staat inter-site replication (voor zover ik kan gokken, was weer tijd geleden) op anderhalf uur ofzo. Dit kun je (en zou ik ook doen) op 15 mins zetten. Waarom het default zo hoog staat weet en snap ik niet, 15 mins is in de meeste gevallen meest ideaal (ja taaltechnisch fout, i know).

Mocht je in de toekomst gaan groeien, en meerdere DC's neer knallen, is het aan te raden om hub (bridgehead) dc's te configureren. In principe gebeurd replication van domain controllers ook niet verder dan 3 hops (als in over 3 DC's, vergeet tcp/ip hops). Dit geldt voor zowel intra-site (dus max 3x8 secs) als inter-site (3x<var> waarbij <var> jouw replicatie waarde is die je zelf gezet hebt.

Deze info is nu misschien niet zo 123 van belang voor jou, maar met beheer is les 1 altijd voorbereid zijn op groei.

en nog wat leuke links voor je:
http://technet.microsoft....rary/cc755994(WS.10).aspx
http://technet.microsoft.com/en-us/library/bb742457.aspx

[alt-92]

Razwer schreef op woensdag 03 november 2010 @ 19:06:
nog een leuke trouwens, default bij het opzetten van een nieuwe site staat inter-site replication (voor zover ik kan gokken, was weer tijd geleden) op anderhalf uur ofzo. Dit kun je (en zou ik ook doen) op 15 mins zetten. Waarom het default zo hoog staat weet en snap ik niet, 15 mins is in de meeste gevallen meest ideaal (ja taaltechnisch fout, i know).

offtopic:
Omdat men nog steeds rekening houdt met het feit dat lang niet overal OC-96² pijpen liggen met trazillionbit bandbreedte maar soms nog lekker een 128bits lijntje over Timboektoe moet gebruiken naar Verweggelegenistan

[Razwer]

alt-92 schreef op woensdag 03 november 2010 @ 20:31:
[...]

offtopic:
Omdat men nog steeds rekening houdt met het feit dat lang niet overal OC-96² pijpen liggen met trazillionbit bandbreedte maar soms nog lekker een 128bits lijntje over Timboektoe moet gebruiken naar Verweggelegenistan

lol dat is best wel onzin. mijn vorige werkgever, 30.000 werknemers (meer zelfs nu geloof ik, ze zijn weer eens op overname pad geweest) en dus een flinke AD, knikkeren gewoon een dc neer op een site met 2mbit sdsl, replication op 15 mins. Exchange ook nog eens remote, lijn trekt het op zijn dooie gemakkie. Soms zelfs sites met 512kbit. werkt prima met 15 mins setting
Aan de ene kant SMTP replication er uit slopen, en aan de andere kant rekening houden met trage lijnen, is een logica die ik niet snel vat.

[Voor 8% gewijzigd door Razwer op 03-11-2010 20:45]

[ActualF06]

Voor nu ziet het plaatje er als volg uit.



De site to site vpn gaat ook gewoon over Internet, maar ik teken het even zo, om duidelijk te maken dat dat een dedicated DSL verbinding is met de andere kant.

Toch vraag ik me nog wel wat dingen af.

Is het niet "beter" om de twee kanten toch niet op te splitsen in verschillende domeinen ? Het is en blijft een webfarm, die natuurlijk veel gevoeliger is voor invloeden van buitenaf. Als het dan lukt om daar in te breken, zitten ze gelijk op ons hele netwerk. als we de domeinen opsplitsen kunnen we het wat beter scheiden lijkt me ?

Iig, nogmaals bedankt allemaal voor de posts.

[Question Mark]

alt-92 schreef op woensdag 03 november 2010 @ 20:31:
[...]

offtopic:
Omdat men nog steeds rekening houdt met het feit dat lang niet overal OC-96² pijpen liggen met trazillionbit bandbreedte maar soms nog lekker een 128bits lijntje over Timboektoe moet gebruiken naar Verweggelegenistan

Dat, en het feit dat dit een waarde is die vanaf Windows 2000 al default op ingesteld staat. Windows 2000 had echter voor replicatie wel wat meer bandbreedte nodig dan de huidige Windows versies.

[Razwer]

ActualF06 schreef op donderdag 04 november 2010 @ 13:11:
Voor nu ziet het plaatje er als volg uit.

[afbeelding]

De site to site vpn gaat ook gewoon over Internet, maar ik teken het even zo, om duidelijk te maken dat dat een dedicated DSL verbinding is met de andere kant.

Toch vraag ik me nog wel wat dingen af.

Is het niet "beter" om de twee kanten toch niet op te splitsen in verschillende domeinen ? Het is en blijft een webfarm, die natuurlijk veel gevoeliger is voor invloeden van buitenaf. Als het dan lukt om daar in te breken, zitten ze gelijk op ons hele netwerk. als we de domeinen opsplitsen kunnen we het wat beter scheiden lijkt me ?

Iig, nogmaals bedankt allemaal voor de posts.

Je kan dat doen idd maar dan zou ik een 2e dc (gc) neerzetten voor dat domein in je datacentre omdat je je fileserver daar niet in dat domein wilt hebben, tenzij die fileserver puur de webservers serveert uiteraard.
De filosofie achter multiple domains is voor in principe autonome sites die min of meer hun eigen beheer willen doen. (bijvoorbeeld PCI) security kan een andere zijn, maar dan is een totaal apart domein eerder een plan ipv een trust (door danwel een subdomain).
Verder is een flat domain structure altijd je uitgangspunt tenzij je echt een zwaarwegende reden hebt om dat niet te doen.

vergeet ook niet dat je als je wilt gaan subdomainen en bijv site1.bedrijf.local en site2.bedrijf.local wilt doen het slim is om het met toplevel structuur te doen. Dit kost je minimaal 2 (mits je fault tollerance wilt) domain controllers extra. bedrijf.local-->2x DC, site1.bedrijf.local-->2x DC, site2.bedrijf.local-->2xDC.
je kan het ook met 1 domain controller doen per domain maar dat zou ik persoonlijk te risky vinden.

[alt-92]

Razwer schreef op woensdag 03 november 2010 @ 20:45:
lol dat is best wel onzin.[....]

Aan de ene kant SMTP replication er uit slopen, en aan de andere kant rekening houden met trage lijnen, is een logica die ik niet snel vat.

Bleek dat zo goed als niemand SMTP repl ooit echt gebruikt, dus waarom dan zo'n feature voor NT6 helemaal from scratch overdoen?
Want een Core DC kan wel, maar SMTP zit niet in Core.

[Razwer]

alt-92 schreef op vrijdag 05 november 2010 @ 20:11:
[...]

Bleek dat zo goed als niemand SMTP repl ooit echt gebruikt, dus waarom dan zo'n feature voor NT6 helemaal from scratch overdoen?
Want een Core DC kan wel, maar SMTP zit niet in Core.

uiteraard, smtp replication is ook bagger gelimiteerd, het is gewoon uit de tijd. De beredenering van Question Mark kan ik me meer in vinden en dat vertaal ik dan naar luiheid aan de kant van MS om dat aspect van replication niet aangepast te hebben aan huidige tijden.

[alt-92]

Ej, dan kunnen de certified prutsers tenminste nog laten zien dat ze dat papiertje waard zijn toch?