Twee locaties, één Active Directory

[CAP-Team]

Ik heb de opdracht gekregen om het volgende te realiseren:

Een bedrijf heeft twee vestigingen. De eerste vestiging heeft een PDC en een Exchange server, de tweede vestiging heeft (nog) een Novell Netware netwerk en staat nu nog volledig los van het netwerk van de eerste vestiging.

Het netwerk van de eerste vestiging draait perfect, gebruikers hebben roaming profiles, printers enz. Dit netwerk heeft als IP range 192.168.130.x

Nu zijn we er aan toegekomen om de tweede vestiging te gaan omzetten. Het is de bedoeling dat we een hardwarematige VPN verbinding gaan opzetten tussen beide vestigingen.

Door de VPN verbinding zal het tweede netwerk een ander IP segment moeten krijgen, we hebben bedacht dat dit 192.168.131.x moet worden.

Voor de tweede vestiging willen we een aparte DC gaan inzetten, de Active Directory en DNS moet tussen beide vestigingen gesynchroniseerd worden.
De tweede DC is al voorgeïnstalleerd, is in het domein van de eerste vestiging gezet, en is verder ingericht als tweede DC.
Nadat dit gedaan is, is het IP segment aangepast, en is de server naar de tweede vestiging verhuisd (2 km afstand).

De DNS service is op de een of andere manier niet geïnstalleerd op deze server en kan daarom ook niet gesynchroniseerd worden, wat wel de bedoeling is.

Beide DC's staan ook in Active Directory, Sites en Services.

Als de Active directory synchronisatie voor elkaar is over de VPN verbinding en een werkstation kan in het domein gezet worden, kan ik verder met de inrichting van de tweede DC.

Is mijn werkwijze correct, of zie ik iets over het hoofd?

Kan dit inrichten als DNS server op de tweede DC achteraf nog gedaan worden, of kan ik beter de tweede DC weer naar de eerste vestiging nemen, de DC demoten en opnieuw inrichten als DC, maar nu met DNS?

[Taigu]

Je kan achteraf gewoon de DNS service erbij installeren.

[Archie_T]

Ik weet natuurlijk niet wat voor VPN er tussen zit (bandbreedte) maar ik zou wellicht ook iets met sites gedaan hebben. Nadeel van deze configuratie vind ik wel dat je IP adres van je 2e DC wijzigt, Kan nog wel eens gekke dingen geven. De rest lijkt mij vrij standaard DC installatie, niets bijzonders.

[JackBol]

Zorg ervoor dat ze allebei GC zijn.

[CAP-Team]

op locatie 1 werkt de replicatie wel (weet niet of dit nog werkt na wijziging van het ip adres, maar het ip adres moet toch aangepast worden ivm VPN), ik heb de dns wel aangepast dat de servernaam van de tweede DC verwijst naar het goede ip adres.

2e DC ook GC, OK, zal ik instellen.

[McMiGHtY]

Is er voordat je ging installeren een design gemaakt, waarin rekening is gehouden met replicatie van de AD, GC, plaats van de fsmo roles etc?

Dit lijkt op:"Goh, tweede dc nodig..ff installeren..dan verhuizen, ipje veranderen en werken"

Misschien heb je hier wat aan:
http://technet2.microsoft...e9f-fd85ffed76601033.mspx

[ Voor 51% gewijzigd door McMiGHtY op 30-01-2006 17:20 ]

[CAP-Team]

McMiGHtY schreef op maandag 30 januari 2006 @ 17:12:
Is er voordat je ging installeren een design gemaakt, waarin rekening is gehouden met replicatie van de AD, GC, plaats van de fsmo roles etc?

Dit lijkt op:"Goh, tweede dc nodig..ff installeren..dan verhuizen, ipje veranderen en werken"

Misschien heb je hier wat aan:
http://technet2.microsoft...e9f-fd85ffed76601033.mspx

De eerlijkheid gebiedt mij te zeggen dat dit inderdaad zo ongeveer de werkwijze was
Het linkje dat je stuurde ziet er erg interessant uit, bedankt!

[McMiGHtY]

Bevestigd nogmaals hoe belangrijk een AD design is.

[Archie_T]

CAP-Team schreef op maandag 30 januari 2006 @ 17:39:
[...]


De eerlijkheid gebiedt mij te zeggen dat dit inderdaad zo ongeveer de werkwijze was
Het linkje dat je stuurde ziet er erg interessant uit, bedankt!

Ik zou dan nog maar even gaan kijken naar een design.. Je kan het waarschijnlijk nu nog opnieuw opzetten en dan maar een week ofzo uitlopen. Zonder design of nadenken kom je jezelf uiteindelijk weer tegen..

[CAP-Team]

Laat ik het anders stellen, dat van de tweede vestiging was nog niet bekend ten tijde van het installeren van de eerste vestiging, deze eis is er pas later bijgekomen.

Men wil op twee vestigingen gebruik maken van één Exchange server, op de tweede vestiging zijn er slechts 3 gebruikers, op de eerste vestiging zijn er 10 gebruikers.
Om de hoeveelheid dataverkeer te ontlasten en om te voorkomen dat men op de tweede vestiging niet kan inloggen als de internet/vpn verbinding eruit ligt, is ervoor gekozen om een tweede DC in te richten en hier ook de data en de roaming profiles van de gebruikers van de tweede vestiging op te slaan.
Beide vestigingen worden gekoppeld via een hardwarematige VPN verbinding met behulp van ZyWall routers/firewalls.

Tja waar begin je dan. Tweede server was er, hier Windows Server 2003 op geïnstalleerd en in het domein gezet. Vervolgens als tweede DC ingericht. Toen kwam de VPN verbinding om de hoek kijken, dat de andere vestiging in een andere IP range moet komen, aangezien anders de VPN niet gaat werken. Toen het IP adres en DNS van de tweede DC aangepast, en toen zat ik 'n beetje vast

[ Voor 75% gewijzigd door CAP-Team op 30-01-2006 21:07 ]

[JackBol]

CAP-Team schreef op maandag 30 januari 2006 @ 21:01:
Tja waar begin je dan. Plan bedenken, Tweede server was er, hier Windows Server 2003 op geïnstalleerd en in het domein gezet. Vervolgens als tweede DC ingericht. Toen kwam de VPN verbinding om de hoek kijken, dat de andere vestiging in een andere IP range moet komen, aangezien anders de VPN niet gaat werken. Toen het IP adres en DNS van de tweede DC aangepast, en toen zat ik 'n beetje vast

[Remco]

Op deze wijze hebben wij ook 10 vestigingen uitgerold over een wan.
Je moet de server ten eerste wel een eigen site geven met bijbehorend ip adres-space.
En je replicatie binnen de sites opzetten.

Het beste kan je dns achteraf installeren (als de server zijn uiteindelijke ip heeft).
Daarna kan je meteen handmatig de synchronisatie testen.

[Verwijderd]

Allereerst ga ik er maar even van uit dat je het hier hebt over windows2003. Verwarrend is wel dat je het hebt over een PDC, dit is uit het NT4 tijdperk en praat je sinds windows 2000 niet meer over, dit is namelijk gebaseerd op een multi-master model.

ik heb de dns wel aangepast dat de servernaam van de tweede DC verwijst naar het goede ip adres

Het is niet verstandig om handmatig wijzigingen in DNS aan te brengen. In dat geval wordt jij namelijk eigenaar van het record en de server niet meer.

Dit kan problemen gaan geven als de server zijn DNS records moet updaten.
Om de server zelf DNS te laten updaten, kun je het beste de netlogon service herstarten, de DC zal dan opnieuw zijn SRV records gaan registreren in DNS.

Op deze wijze hebben wij ook 10 vestigingen uitgerold over een wan.
Je moet de server ten eerste wel een eigen site geven met bijbehorend ip adres-space.
En je replicatie binnen de sites opzetten.

Het gebruik van sites hangt af van de snelheid en betrouwbaarheid van de verbinding. Aangezien je het in een stukje had over het beperken van dataverkeer over de lijn zodat logins van gebruikers niet verstoord kunnen worden, zou ik het gebruik van sites wel aanraden. De tweede DC dus in zijn eigen site zetten.

Zo kun je namelijk beter je replicatie verkeer controleren, en bepalen wanneer er gerepliceerd wordt.

Replicatie binnen sites hoef je niet op te zetten, dit gebeurd automatisch door de KCC. (je kunt dit wel wijzigen, maar is meestal niet nodig)

Wat wel belangrijk is, is om je inter-site replicatie op te zetten. ALLE replicatie tussen de sites zal gebeuren met "respect" voor de site-link. kortom, als AD wil repliceren zal deze dat altijd doen met de intervallen aangegeven op de site-link.

ik neem ook aan de je je DNS active Directory integrated hebt gemaakt?. in dat geval wordt DNS replicatie gewoon onderdeel van je AD replicatie, en zijn dit geen afzonderlijke gevallen meer.

gezien je in deze kleine organisatie maar 1 domain in je forest zal hebben, kun je idd beide DC's GC maken. Als er 2 of meerdere domains zouden zijn, moet je rekening houden met een stuk meer replicatie verkeer.

Als je hier allemaal rekening mee gehouden hebt, moet je vervolgens nog wel even kijken of er geen verkeer\poorten geblocked worden door de ZyWall firewalls waar je het over had.

[ Voor 3% gewijzigd door Verwijderd op 03-02-2006 09:41 ]