[Migratieperikelen] Alle NT servers zijn domein controller

[collin]

Vraagstukje voor de (ervaren) migrant ( )

Ik ben net begonnen bij een nieuwe opdracht. Ik moet hier een plan opstellen voor de migratie en ik zou het fijn vinden als jullie een beetje meedenken en dat we samen hier ook nog misschien wat van opsteken.

Het is een kleine omgeving bestaande uit 40 werkstations (98, 2000 en XP door elkaar heen) 7 server, waarvan 2 Windows 2000 member servers en de overige servers zijn 5 (!!) NT4 domein controllers, waarop ook applicaties, exchange, printers, files etc op staat. De filosofie was, waarom maak je van zo'n ding niet meteen een domein controller?

Destijds een leuke gedachte, nu met een migratie is dat gewoon een stuk minder. Normaal gesproken kan je de domein controllers migreren en stap voor stap de servers beetpakken zeg maar. Maar nu het domein controllers zijn, heb ik dus ook al niet de optie om alleen de domeincontrollers helemaal opnieuw in te richten (40 gebruikers da's geen probleem) en de applicatie/file/print servers simpelweg in het nieuwe domein te hangen, mits ik alles tegelijk doe, maar daar ben ik niet zo'n fan van.

Het is een stichting dus ik kan ook niet een hele nieuwe omgeving ernaast bouwen en dan langzaam de data migreren, de bestaande machines moeten gemigreerd worden.

Nu kan je ook niet ff 1 BDC syncen en in de kast zetten, mocht de migratie mislukken, want al die andere servers zijn ook DC en dus moeten die dan ook meteen opnieuw geinstalleerd worden, in geval van fall back.

Ik zit te denken om het toch maar server voor server aan te pakken, backup van alles wat erop draait, 2000 (of 2003) CD erin, installeren en de services die erop draaide er weer terug te zetten, maar dit keer er GEEN domein controller ervan maken. Totdat ik nog 1 of 2 domein controllers over heb die ik netjes kan migreren naar AD.

Lang verhaal, ik hoop dat het een beetje duidelijk is en het is weer een voorbeeld van het feit dat afwijken van Microsoft's best practices meestal leidt tot problemen, vroeg of laat. Wie heeft er nog tips?

[zomertje]

Twee domeincontrollers is wel aan te bevelen ja. Dan kunnen ze elkaars backup zijn voor de AD taken.

Er is een rare bug trouwens: als je een grote hoeveelheid bestandjes naar een domain controller copieert en je laat de verkenner openstaan dan is het enorm traag. Sluit je de verkenner, en het gaat als een trein Microsoft erkent dit probleem maar er is nog geen fix (voor zover ik weet).

[McMiGHtY]

Als ik jou was zou ik dit in een weekeinde doen en dan alles omzetten.
In de voorbereiding een aantal servers zo goed als leegmaken, zodat je deze in kan zetten als DC's.

[collin]

zomertje schreef op 14 april 2004 @ 14:55:
Twee domeincontrollers is wel aan te bevelen ja. Dan kunnen ze elkaars backup zijn voor de AD taken.

Er is een rare bug trouwens: als je een grote hoeveelheid bestandjes naar een domain controller copieert en je laat de verkenner openstaan dan is het enorm traag. Sluit je de verkenner, en het gaat als een trein Microsoft erkent dit probleem maar er is nog geen fix (voor zover ik weet).

OK, dat is ook fijn om te weten ja. En meteen een argument om van de fileserver geen DC te maken.

[ Voor 72% gewijzigd door collin op 14-04-2004 15:09 ]

[Qwerty-273]

zomertje schreef op 14 april 2004 @ 14:55:
Er is een rare bug trouwens: als je een grote hoeveelheid bestandjes naar een domain controller copieert en je laat de verkenner openstaan dan is het enorm traag. Sluit je de verkenner, en het gaat als een trein Microsoft erkent dit probleem maar er is nog geen fix (voor zover ik weet).

Dat is toch al heel lang in Windows? Bij een move van een grote lap bestanden, als je de verkenner openlaat staan dat het dan trager gaat dan wanneer deze geminimaliseerd is. Of is dit een ander probleem?

[Verwijderd]

Nu kan je ook niet ff 1 BDC syncen en in de kast zetten, mocht de migratie mislukken, want al die andere servers zijn ook DC en dus moeten die dan ook meteen opnieuw geinstalleerd worden, in geval van fall back.

als je de luxe hebt zou ik dat wel doen... voor migratie maakt het allemaal niet zoveel uit. als je een upgrade wil doen moet je toch beginnen met de pdc te upgraden en of je daarna nog 1 bdc moet doen of 4 maakt mijn inziens weinig uit. allemaal weer dc maken is idd wel wat overbodig in deze situatie...

[collin]

Verwijderd schreef op 14 april 2004 @ 15:16:
[...]


als je de luxe hebt zou ik dat wel doen... voor migratie maakt het allemaal niet zoveel uit. als je een upgrade wil doen moet je toch beginnen met de pdc te upgraden en of je daarna nog 1 bdc moet doen of 4 maakt mijn inziens weinig uit. allemaal weer dc maken is idd wel wat overbodig in deze situatie...

Ja ik zet ook wel een BDC in de kast, voor de zekerheid, maar als ik weer terug wil naar die oude SAM, heb ik wel een probleem met alle overige BDC's lijkt me. Misschine zijn die om zeep gegaan door een rotte migratie, dan zal ik ze moeten reinstallen of restoren van tape en in het laatste geval heb ik dan die BDC niet nodig.

[SED]

NT4 mmm, even geleden, maar begrijp ik het goed dat je een PDC hebt en vier BDC's?
Je hebt dus wel "een" domein?

stap 0:
maak backups van alle essentiele data zodat je bij problemen terug kunt.
Test eventueel een backup om de controleren of je hardware ook daadwerkelijk werkt.

Stap 1:
haal BDC fysiek uit domain en promoot die tot PDC. vervolgens migreer je die naar windows 2003

Stap 2.
Haal de PDC of-line en meld alle nt bakken aan bij het nieuwe w2k3 domain.

stap 3
upgrade alle nt4 servers naar w2k3

stap 4
test je omgeving en kijk of alles werkt.

stap 5 demote je pdc en hang die ook in het domain, daarna upgrade draaien.

stap 6 verdeel eventueel enkele van de fsmo rollen overde domaincontrollers om zo de werking te optimaliseren.

stap 7 pak een pilsje of een cola en scheld op de stomme adviezen die je gekregen hebt.

[Brahiewahiewa]

SED schreef op 14 april 2004 @ 19:07:
[...]
Stap 2.
Haal de PDC of-line en meld alle nt bakken aan bij het nieuwe w2k3 domain.

Hier gaat je plan dus fout, want je kunt een BDC (alle NT servers van TS zijn BDC) niet zomaar effe in een nieuw domain aanmelden.

@TS: wat weerhoudt je ervan om al je machines gewoon te upgraden van NT4 naar 2k3? Je eindigt dan met allemaal DC's, maar die kun je met DCPROMO gewoon weer demoten

[SED]

Brahiewahiewa schreef op 14 april 2004 @ 20:22:
[...]
Hier gaat je plan dus fout, want je kunt een BDC (alle NT servers van TS zijn BDC) niet zomaar effe in een nieuw domain aanmelden.

@TS: wat weerhoudt je ervan om al je machines gewoon te upgraden van NT4 naar 2k3? Je eindigt dan met allemaal DC's, maar die kun je met DCPROMO gewoon weer demoten

Dus stap 2 en 3 omdraaien?

[Verwijderd]

ik snap niet waarom je een promote to pdc wilt doen?

als je de huidige pdc upgrade naar win2k3 zou het domain nog moeten werken (ik weet even niet of je win2k3 kan draaien met nt4 bdc's). mocht daar iets misgaan heb je nog 4 bdc's over waarvan je er weer 1 zou kunnen promoten. is de upgrade wel goed gegaan kan je met de andere servers doen wat je wilt (upgraden of herinstalleren), want alle gebruikers etc. zitten al in het "nieuwe" domain.

[ Voor 6% gewijzigd door Verwijderd op 15-04-2004 14:01 ]

[Zwelgje]

Verwijderd schreef op 15 april 2004 @ 14:00:
ik snap niet waarom je een promote to pdc wilt doen?

als je de huidige pdc upgrade naar win2k3 zou het domain nog moeten werken (ik weet even niet of je win2k3 kan draaien met nt4 bdc's). mocht daar iets misgaan heb je nog 4 bdc's over waarvan je er weer 1 zou kunnen promoten. is de upgrade wel goed gegaan kan je met de andere servers doen wat je wilt (upgraden of herinstalleren), want alle gebruikers etc. zitten al in het "nieuwe" domain.

windows 2003 kan gelukkig in ''interim'' mode draaien (met nt4 bdc's dus)

[collin]

Het blijft lastig.. als door de migratie de user database om wat voor reden dan ook corrupt raakt, zal ik alle servers moeten herinstalleren, omdat op alle servers de user database dan verrot is. Tis niet anders.. We zullen waarschijnlijk in een weekend alles tegelijk moeten upgraden.

[Verwijderd]

stel je upgrade de pdc naar win2k3 interim en dat gaat mis, dan zijn op dat moment je bdc's nog goed. 1 van de bdc's promoten en je hebt weer een werkend nt4 domain. naar mij idee kan je dus 4 keer een upgrade verkloten voordat je echt een probleem hebt . maar dan hebben we natuurlijk nog een goede backup die vantevoren gecontroleerd is...

[SED]

Verwijderd schreef op 15 april 2004 @ 14:00:
ik snap niet waarom je een promote to pdc wilt doen?

.

Als je een BDC met succes tot PDC kunt promoten dan weet je dat het met de userbase allemaal goed zit. Je systeem draait dan in de basis goed. Ik weet uit de NT4 tijd.... heeeel lang geleden... dat er regelmatig problemen waren met BDC die niet probleemloos tot PDC waren om t ezetten door allerlei vage problemen. Dat wil je in een groot upgradeproces niet hebben dus een van de beste testen was dan eerst een bdc promoten.
Daarnaast lijkt het me zinvol om de echte PDC even uit het netwerk te halen zodat je probleemoos een fall back hebt en op basis van de BDC's je migratie te voltooien.

[PeterB]

Misschien verdient de volgende benadering gebaseerd op de methode van SED wat onderzoek:

- Haal een BDC uit het netwerk (of genereer een nieuwe op basis van een dikke PC), promote naar PDC, domein renamen, upgraden naar W2K3

- Hang vervolgens het oude domain als trusted onder het nieuwe, en laat de gebruikers authenticeren aan het nieuwe domain

- Daarna kun je redelijk eenvoudig het oude domein server voor server consolideren in het nieuwe.

Er zijn uiteraard heel wat haken en ogen, onder andere met de koppeling van user accounts aan exchange mailboxen. Met 40 gebruikers zijn die waarschijnlijk wel in een uurtje om te zetten.

Het is wel zaak dit principe met een kleine Lab opstelling uit te testen. Een punt van zorg is hier namelijk het feit dat het oude en nieuwe domein eigenlijk het zelfde zijn. Zelfde security identifier of zo.

edit:
Overigens haddenwij in ons netwerk ook een clubje van zo'n 10 servers die allemaal NT4 domain controller waren. Reden hier was het feit dat de users in een ge-outsourced account domain zaten, en toegang tot server resources geregeld werd met 'local groups'. Door alle servers domain controller te maken, werd de scope van de local groups uitgebreid naar het hele resource domain.

[ Voor 37% gewijzigd door PeterB op 17-04-2004 01:40 ]

[Zwelgje]

PeterB schreef op 17 april 2004 @ 01:30:
Misschien verdient de volgende benadering gebaseerd op de methode van SED wat onderzoek:

- Haal een BDC uit het netwerk (of genereer een nieuwe op basis van een dikke PC), promote naar PDC, domein renamen, upgraden naar W2K3

- Hang vervolgens het oude domain als trusted onder het nieuwe, en laat de gebruikers authenticeren aan het nieuwe domain

je moet alleen na afloop dan wel a) alle pc's bijlangs om ze in het nieuwe domain te hangen of b) je gebruikt ADMT om alle computeraccounts over te zetten naar het nieuwe domain

- Daarna kun je redelijk eenvoudig het oude domein server voor server consolideren in het nieuwe.

Er zijn uiteraard heel wat haken en ogen, onder andere met de koppeling van user accounts aan exchange mailboxen. Met 40 gebruikers zijn die waarschijnlijk wel in een uurtje om te zetten.

Het is wel zaak dit principe met een kleine Lab opstelling uit te testen. Een punt van zorg is hier namelijk het feit dat het oude en nieuwe domein eigenlijk het zelfde zijn. Zelfde security identifier of zo.

edit:
Overigens haddenwij in ons netwerk ook een clubje van zo'n 10 servers die allemaal NT4 domain controller waren. Reden hier was het feit dat de users in een ge-outsourced account domain zaten, en toegang tot server resources geregeld werd met 'local groups'. Door alle servers domain controller te maken, werd de scope van de local groups uitgebreid naar het hele resource domain.

zelf zou ik gewoon de nieuwe server voorzien van nt4 en in het oude domain hangen als BDC, vervolgens een BDC offline halen (als backup) en de nieuwe server promoten naar nt4 PDC, deze server ga je dan upgraden naar windows 2003. als dat klaar is zorg ga je de andere BDC's upgraden naar 2003

zo hoef je geen pc's bijlangs om ze in het nieuwe domain te hangen, en hebben de gebruikers er (bijna) geen last van