[2003] AD Groepen structuur vraagje (duplicates gebruiken?)*

[salvador4]

Ik ben momenteel een AD(2k3) aan het inrichten en vraag me af hoe ik het beste kan handelen bij het volgende;

Eén bedrijf met vestigingen in meerdere landen. Ik wil in elke land dezelfde groepen hebben omdat er nu eemaal de zelfde afdelingen zijn. Ik heb voor elk land en OU aangemaakt met daar binnen in weer OU's waar groepen en gebruikers in moeten komen te hangen. Dat lukt niet omdat je niet de zelfde groep namen mag aanmaken (logisch opzich). Ik had gehoopt dat je bv rechten als land.group kon meegeven of iets in die trand.

Nu kan ik uiteraard wel groepen maken als NL Managers en BE Managers maar dat vind ik een beetje rommelig.

Hoe kan ik dit het beste afvangen?

BVD

[mutsje]

je mag op 1 domain niet groepen met zelfde namen aanmaken maar als het verspreid over de wereld is neem ik aan dat je met sites gaat werken?

bedrijf.domain.nl
site.bedrijf.domain.nl
etc

hier de groepenstructuur in hangen

[salvador4]

Ik had moeten melden dat het hier om een Terminal Server gaat, en ik maar 1 DC heb. Zal ik dan met landcodes in groep namen moeten gaan werken, of is er nog een betere methode?

[leon1e]

Je moet dan met landcodes gaan werken, je kunt nu eenmaal geen duplicates gebruiken binnen 1 site. Om hoeveel gebruikers gaat het, en hoeveel terminal server's ga je wegzetten?

Ik pas nog even de topic titel aan, zodat deze iets duidelijker is.

[salvador4]

Het gaat om 5 landen met in het totaal max 80 concurrrent users die op 1 terminal server gaan werken. Ik ga weer verder met m'n huidige opzet inc. landcodes

[ Voor 20% gewijzigd door salvador4 op 24-12-2004 21:23 ]

[alt-92]

80 concurrent users op 1 server?

ouch...

Heb je dat ook berekend of is dat lossevingerwerk?

[salvador4]

Daar is wel enigszins over nagedacht ja :}

Met een quad systeem met 4+ gig geheugen, snelle scsi schijven in raid zal ik iig een heel eind komen.

De sessies worden redelijk eenvoudige office omgevingen met her en der wat extra programmatuur. Soortgelijke situaties lopen elders met 40/50 users prima op dual systemen (wel dikke).

[sanfranjake]

Ik zet nog even je OS, [2003] vooraan in de titel

[mutsje]

salvador4 schreef op zaterdag 25 december 2004 @ 00:03:
Daar is wel enigszins over nagedacht ja :}

Met een quad systeem met 4+ gig geheugen, snelle scsi schijven in raid zal ik iig een heel eind komen.

De sessies worden redelijk eenvoudige office omgevingen met her en der wat extra programmatuur. Soortgelijke situaties lopen elders met 40/50 users prima op dual systemen (wel dikke).

een quad systeem zal je performance amper opboosten. 4GB memory trekt het waarschijnlijk net als er 80 users op zitten maar heb je al nagedacht als er hardware uitknalt en 80 users niet meer kunnen werken... je zet het systeem niet redundant op dus...

[leon1e]

mutsje schreef op zaterdag 25 december 2004 @ 14:47:
[...]

een quad systeem zal je performance amper opboosten. 4GB memory trekt het waarschijnlijk net als er 80 users op zitten maar heb je al nagedacht als er hardware uitknalt en 80 users niet meer kunnen werken... je zet het systeem niet redundant op dus...

With ^

Maar nog even een vraag, ga je op deze terminal server ook de DC / File / Print service's draaien?

[salvador4]

DC; aparte server, file services op een database server. Print services zal er wel op komen te draaien.

Als er hardware klapt heb ik zowieso gezeik, er is ook nog een db server, en zonder deze heb ik niks aan de ts server. dan kan ik er daar ook 2 van weg zetten, en zo zijn er nog wel wat servers die ik niet kan missen. Alle systemen draaien in raid5, redundant psu's, en voor de vpn's multi lijnen.

Jullie hebben uiteraard een punt, maar je hebt helaas ook nog iets als kosten, en deze zouden dan aanzienlijk hoger liggen. En daarbij, uitbreiden kan altijd nog.

[ Voor 3% gewijzigd door salvador4 op 25-12-2004 17:44 ]

[elevator]

Het wegzetten van een hele zware terminal server is vaak duurder dan het wegzetten van twee lichte (dual cpu's, 2 gb geheugen) terminal servers.

Zeker als je kijkt naar bv. een service window (wat doe je als je 's avonds mensen hebt die willen werken op die TS? Wacht jij dan tot ze ooit eens uitloggen met onderhoud?) en dergelijke.

Daarnaast moet je rekening houden met dingen die mis gaan (wat doe je op je quad CPU machine als er een process aan het crashen is wat je CPU voor 100% belast. Er zitten dan wel - als het ware - 20 man op die ene CPU)

Daarnaast heb je één DC - ook dat lijkt me veel te weinig om een serieuze setup te maken. Wat dat betreft zou ik je aanraden - ook al is het maar op een PC - om een tweede DC in te zetten zodat je bij uitval van je DC in ieder geval nog terug kan vallen op die backup DC.

Uiteraard is (in jouw geval zo) dat als je DB server weg valt dat je users dan alsnog niet kunnen werken. Je creert nu echter een situatie waarin als of de DB server, of de TS, of de DC, of ... uitvalt dat je dan gezeik hebt. Met elke server die je hier aan toevoegt vergroot je dus je probleem

Dan als laatste. Als mensen het zelfde werk doen, en ze toch centraal tot een fileserver toegang hebben - waarom zet je ze dan niet in een grote groep die land overkoepelend is?

[salvador4]

Bedankt voor je duidelijke reply elevator, een aantal punten zal ik zeker in overweging nemen.

Waarom de keuze voor een quad? Tja die keuze was er eigenlijk niet, de klant had deze al in z'n bezit. Alleen draaide deze maar op 2 cpu's, en zijn er 2 bij gekomen.

Over je laatste vraag, de mensen die hetzelfde werk doen zullen ook in 1 groep komen, maar ik ontkom er toch niet aan om sommige afdelingen per land te scheiden.

[mutsje]

ga de klant dan maar eens een calculatie model voor zijn neus houden wat het de klant kost om 2 kleine machines (dl360 of 380 G4) aan te schaffen en deze TS te laten hosten of 1 machine, wat ik hier mee bedoel is als het eruit knalt natuurlijk. Even kosten baten analyse maken en de klant zal waarschijnlijk inzien dat er toch een groot risico is als je het niet redundant uitvoert.

helaas is het wel vaak zo dat je niet veel te kiezen hebt maar breng dan in ieder geval de klant op de hoogte van de mogelijke risico's die de klant loopt bij uitval.