Verplaatsing 2de DC naar een andere vestiging

[Bo3r]

Wij hebben 2 DC's draaien, 1 van deze 2 willen we naar een andere vestiging verhuizen. De 2 dc's draaien nu op een zelfde locatie, in hetzelfde IP-segment (192.168.1.X) met Windows Server Enterprise R2 2003 SP2.

De andere vestiging maakt connectie met ons via een IP-sec tunnel. De LAN kant van deze vestiging heeft als netwerk-range 192.168.106.X)
Mijn vraag is nu of 2 DC's kunnen samenwerken als deze niet tot dezelfde IP-Range behoren.

Iemand hier reeds ervaring mee?

Alvast bedankt voor de hulp!

Nick

[Verwijderd]

Geen idee wat een DC is, maar 192.168.1.X en 192.168.106.X zijn beiden onderdeel van het 192.168.X.X netwerk zover ik zie... gewoon op je DC's de subnet maskers veranderen in 255.255.0.0 i.p.v. 255.255.255.0

Modbreak:

Als je niets nuttigs te melden hebt, of je weet niet waar het over gaat, hou je dan buiten de discussie

[ Voor 24% gewijzigd door Equator op 08-04-2010 10:29 ]

[DarkSide]

Als de andere computers gewoon verbinding hebben met AD dan moet de nieuwe DC dat ook gewoon kunnen.
Verplaats de DC ook even in AD sites en computers. Tenminste ik neem aan dat de andere sites gedefinieerd zijn. Wel zo handig bij het aanloggen.
Voor de rest weet ik niet hoe je netwerk in elkaar steekt. Subnetmasks. Rollen e.d. Zodat de 2e DC ook bv GC gaat draaien.
Waarom wil je precies de DC verplaatsen.

[kKaltUu]

Verwijderd schreef op woensdag 07 april 2010 @ 15:23:
Geen idee wat een DC is, maar 192.168.1.X en 192.168.106.X zijn beiden onderdeel van het 192.168.X.X netwerk zover ik zie... gewoon op je DC's de subnet maskers veranderen in 255.255.0.0 i.p.v. 255.255.255.0

DC is een domaincontroller.

Bo3r, ligt er een dedicated lijn tussen de 2 locaties, of wordt het via het web gerouteerd?

[Trommelrem]

Bo3r schreef op woensdag 07 april 2010 @ 15:16:
Mijn vraag is nu of 2 DC's kunnen samenwerken als deze niet tot dezelfde IP-Range behoren.

Iemand hier reeds ervaring mee?

Jawel hoor, dat is geen probleem. Zorg er wel voor dat je de verplaatste DC in een nieuwe site zet en dat er genoeg site connectivity is (zie AD Sites and Services en Event Log).

[ Voor 5% gewijzigd door Trommelrem op 07-04-2010 15:33 ]

[Verwijderd]

ik weet verder niet war deze dc allemaal moet kunnen? (rodc etc)
anders zou je ook eens kunnen overwegen om met trusts te werken.
dit zou namelijk een valide optie zijn mocht de ze dc in een ander domein zitten.

[Ethirty]

Verwijderd schreef op woensdag 07 april 2010 @ 15:23:
Geen idee wat een DC is, maar 192.168.1.X en 192.168.106.X zijn beiden onderdeel van het 192.168.X.X netwerk zover ik zie... gewoon op je DC's de subnet maskers veranderen in 255.255.0.0 i.p.v. 255.255.255.0

Sorry, maar zeg dan niks. Hoe wil je dat gaan routeren met zo'n subnet...

Verwijderd schreef op woensdag 07 april 2010 @ 23:00:
ik weet verder niet war deze dc allemaal moet kunnen? (rodc etc)
anders zou je ook eens kunnen overwegen om met trusts te werken.
dit zou namelijk een valide optie zijn mocht de ze dc in een ander domein zitten.

Dan moet hij een heel nieuw domein gaan maken

Het antwoord is heel simpel
- maak in AD sites en services netjes je LAN segmenten en locaties aan en geef de 2e DC ook even de tijd om die gegevens te repliceren voor je hem uit zet (15-30 minuutjes is meer dan zat schat ik zo)
- verhuis je DC naar locatie B en geef hem een nieuw IP adres
- DC 'weet' dat hij in andere locatie zit en past zijn replicatie schema daarop aan.

Ik zou de DC met de FSMO rollen (meestal de 1e DC) laten staan op de grootste vestiging of het dichts in de buurt van beheer, maar dat is meer voorkeur dan regel.

[Trommelrem]

Verwijderd schreef op woensdag 07 april 2010 @ 23:00:
ik weet verder niet war deze dc allemaal moet kunnen? (rodc etc)
anders zou je ook eens kunnen overwegen om met trusts te werken.
dit zou namelijk een valide optie zijn mocht de ze dc in een ander domein zitten.

RODC is pas mogelijk sinds Windows 2008.
De topicstarter moet gewoon even Googlen, want hierover is zo veel informatie te vinden bij zo veel verschillende configuraties dat hij hier op GoT echt niet het antwoord zal krijgen wat specifiek bij hem past.

[DeeJee]

Verwijderd schreef op woensdag 07 april 2010 @ 23:00:
ik weet verder niet war deze dc allemaal moet kunnen? (rodc etc)
anders zou je ook eens kunnen overwegen om met trusts te werken.
dit zou namelijk een valide optie zijn mocht de ze dc in een ander domein zitten.

Trusts maak je om domeinen te verbinden. Geen idee waarom je die in dit geval nodig zou hebben.

[kcRogue]

-

[ Voor 99% gewijzigd door kcRogue op 09-04-2010 11:25 . Reden: niet dan -O- ]

[elevator]

kcRogue's post moet je gewoon negeren.

Naast wat Ethirty al zegt, moet je ook niet vergeten de DNS server instellingen op beide DC's aan te passen zodat ze naar zichzelf en naar hun vriendje wijst

[Ethirty]

Uiteraard, die had ik er voor de volledigheid ook even bij moeten zetten. Ging er vanuit dat DNS instellingen op een DC toch wel minimum kennis was

[Question Mark]

Ethirty schreef op woensdag 07 april 2010 @ 23:09:
[...]

- DC 'weet' dat hij in andere locatie zit en past zijn replicatie schema daarop aan.

Dat weet hij nou nét niet automatisch. Je zult hem handmatig moeten verplaatsen in AD sites & services. (En daar heb ik me echt over verbaasd toen ik daar eens tegen aanliep).

Zie ook: Moving a Domain Controller to a Different Site

Stap 6 van het stappenplan: Move the Server object to the new site

[Ethirty]

I stand corrected...

[Question Mark]

Ethirty schreef op donderdag 08 april 2010 @ 19:58:
I stand corrected...

Ik wist het de eerste keer ook niet. Je gaat er eigenlijk automatisch vanuit dat dit vanzelf gaat. Ook aangezien een bijgeplaatste nieuwe DC wél automatisch de juiste site selecteerd.

Question Mark heeft toen behoorlijk lang "op de replicatie gewacht" en de netlogon service ed al ongeduldig meerdere malen herstart, voordat hij erachter kwam dat dit dus niet vanzelf ging

[Bo3r]

Intussen is de 2de DC verplaatst en werkt perfect. De juist DNS-instellingen configureren en de DC's kunnen wederom vlot samenwerken.
Iemand vroeg me waarom we de 2de DC verplaatst hebben, wel hierom:

Deze nieuwe locatie hebben we opgekocht en bevat ongeveer 20 pc-gebruikers. Op zich geen groot probleem aangezien 90% van onze (administratieve) werkzaamheden via Terminal-servers gebeurt. Enkel een deftige internetverbindingen should do the trick!
Met het plaatsen van een DC op locatie is het lokaal aan -en afmelden op pc's een stuk sneller. Dit is nog allemaal normaal. Maar onze leverancier (zowel hardware als ondersteuning) beweerde dat Terminal en file-sharing ook sneller zou werken. Onze Terminal -en fileservers staan echter wel op de originele locatie!
Dit klinkt inderdaad nogal vreemd maar het maakt effectief een verschil.

In ieder geval iedereen bedankt voor de verstrekte hulp!