Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

[Windows Servers] Domein opsplitsen in 2 domeinen

Pagina: 1
Acties:

Verwijderd

Topicstarter
Mede-tweakers,

Ik sta momenteel voor een kleine uitdaging en heb wat advies nodig. De situatie:
Momenteel maakt een klant van ons gebruik van een aantal Hyper-V hosts waarop zo'n 50 virtuele servers draaien. De klant gaat intern wat afdelingen van elkaar scheiden, één afdeling verhuisd naar een ander pand, business-activiteiten worden gescheiden, en het netwerk moet ook gescheiden worden van het huidige netwerk.

Wat er dus gaat gebeuren:
  • Op de nieuwe locatie komt er een extra Hyper-V host waarop een nieuwe DC wordt ingericht.
  • Vanaf de oude locatie wordt er een Hyper-V host meegenomen naar de nieuwe locatie, waarop rond de 25 VM's draaien welke overgezet moeten worden naar het nieuwe domein.
  • De virtuele servers (VM's), clients, firewall en printers moeten op het nieuwe domein worden aangemeld.
Microsoft zojuist gebeld, er is geen tool beschikbaar waarmee de 25 VM's een ander domein kunnen joinen. De servers moeten handmatig omgezet worden naar het nieuwe domein. Dit opzich is geen probleem, maar met de authenticatie van de applicaties en services op de VM's kan er heel wat mis gaan na omzetting.

Wat geen opties zijn voor deze situatie (wel over nagedacht):
  • Een IP-VPN of IP-sec tunnel realiseren tussen oude en nieuwe locatie, op nieuwe locatie extra DC inrichten die repliceert met huidige DC en VM's laten voor wat het nu is.
  • Een tweede domein aanmaken die verbinding maakt met dezelfde forest, zodat er een trust is en de VM's niet aangepast hoeven te worden.
Het netwerk op de nieuwe locatie moet zowel fysiek als administratief totaal gescheiden worden.

Heeft iemand deze situatie weleens meegemaakt? Zo ja, hoe is hiermee omgegaan? Tooling o.i.d. gebruikt om servers om te zetten naar nieuw domein? Is handmatig overzetten echt nodig?

Arend

  • Zwelgje
  • Registratie: November 2000
  • Laatst online: 20:14
Microsoft gebeld en die gaven aan dat er geen tools is om servers over te zetten naar een ander domain :? ze maken notabene zelf een tool die dit gewoon kan

http://www.microsoft.com/...x?displaylang=en&id=17918

fully automated unjoinen van een domain en rejoinen naar een nieuw domain.. wat wil je nog meer? useraccounts meenemen, passwords meenemen, the works

A wise man's life is based around fuck you


Verwijderd

Topicstarter
Powershell,

Dank voor je reactie, ADMT ziet er goed uit. Is het echt zo simpel als de tool zegt:
  1. Nieuwe DC (domein) inrichten.
  2. ADMT uitvoeren.
  3. Servers (domainmembers), users, groups overzetten.
  4. Et cetera.
Brengt ADMT geen wijzigingen aan op de oude/huidige DC? En wat betreft bijvoorbeeld de applicatieserver, ftp-server, SQL-server? Naamswijzigingen hebben toch wel degelijk invloed daarop?

[ Voor 17% gewijzigd door Verwijderd op 14-12-2011 15:04 ]


  • Question Mark
  • Registratie: Mei 2003
  • Laatst online: 30-11 15:27

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

Lees even de manuals en guides door van de ADMT, daar zit nl. nog wel een klein stukje voorbereiding bij.

Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B


  • mookie
  • Registratie: Juni 2002
  • Laatst online: 15-06 08:37

mookie

Heerlijk Helder

ADMT kan niet alles, maar wel veel.

De eerste opmerking is dat ADMT niet gebruikt dient te worden om domeinen op te splitsen, maar enkel om ze samen te voegen of te herstructureren.
Waarom snap ik ook niet helemaal.

Je hebt 2 opties, beide zijn niet echt aantrekkelijk:

Optie 1:
Pak 1 DC die volledig gesynchroniseerd is maar geen enkele FSMO rol heeft.
Zet hem op een ander IP adres/andere range, liefst andere switch, compleet geisoleerd en zorg dat hij nooit meer contact maakt met je huidige netwerk.
Met ntdsutil de rollen "seizen" en overzetten op deze DC.
Alle oude DC's verwijderen met ntdsutil / DNS opschonen.
Daarna andere servers/computers toevoegen aan je nieuw netwerk/nieuwe IP range en ze blijven gewoon werken want er is niet 1 SID gewijzigd.
Je krijgt dan een "fork" van je huidige netwerk, met alle nadelen vandien.
Je kunt die 2 dus echt nooit meer aan elkaar koppelen, en ook kun je ze niet meer terug in elkaar migreren.

Optie 2: veel beter maar niet ondersteund en werkt ook niet voor alles:
Nieuwe DC installeren en daarop een nieuw domein beginnen.
2-way trust maken tussen beide domeinen.
ADMT op die nieuwe DC installeren.
Dan kun je alle gebruikers en groepen makkelijk migreren, ADMT zet ook alle users weer in de juiste groups etc.
Verders kan ADMT automatisch alle rechten op alle clients/servers aanpassen, user profiles migreren zodat je niet met een lege desktop begint, computers automatisch op het andere domein overzetten etc.

Het nadeel hierin is dat de daadwerkelijke migratie ineens moet gebeuren.
Dus zodra je gaat switchen is het van belang dat b.v. je fileserver al in het nieuwe domein zit en dat je al je gebruikers ineens overzet.
je zult namelijk (of waarschijnlijk) "domain local groups" rechten hebben gegeven op bestanden etc.
Die DLG's werken alleen binnen het domein waar de server zich bevindt.
Dus als je fileserver in domein A zit en je hebt alle rechten gemigreerd zodat DLG's uit domein A en B rechten hebben dan werken alleen de groepen uit domein A.
Totdat je die server overzet naar domein B, dan werken alleen de groepen uit domein B.

Dus in andere woorden:
Zet je nieuwe domein op, maak een 2way trust.
Migreer alle gebruikers, alle groepen, migreer de rechten op de servers in "add" mode,
Zet in 1 tijdspanne alle computers/servers over naar het nieuwe domein.
Migreer de rechten in "remove" mode
Verwijder je trust.

Nadeel is dat ADMT geen rechten aanpast op SQL servers, exchange mailboxes etc etc
Het doet enkel standaard windows dingen zoals bestanden en service logon accounts.


Dus optie 1 is smerig maar werkt heel snel en effectief
Optie 2 is een veel nettere manier, ondanks dat hij niet wordt ondersteund, maar veel meer werk.

Maar volgens mij is het uurtje factuurtje dus ik zou zeggen: optie 2.

mookie


Verwijderd

Topicstarter
Dank voor jullie reacties.

ADMT blijkt dus niet de juiste tool te zijn voor deze situatie. Beide opties die mookie voorstelt zijn inderdaad niet aantrekkelijk (zoals hij zelf al aangeeft). Volgens mij neem ik veel onbenodigde troep mee naar het nieuwe (schone) domein, en is het nog maar afwachten of het werkt zoals het behoort te werken. Nu gaat het slechts om een tiental servertjes, maar wat als je honderden servers hebt? Heeft Microsoft niet nagedacht over dergelijke situaties, of is het spelen met ADMT en trusts?

Microsoft heeft me teruggemaild en ik krijg het advies om een nieuw domain op te zetten, een trust tot stand te brengen zodat User A in domain B kan en User B in domain A. Niet handig dus, want de netwerken moeten gescheiden worden.

  • Question Mark
  • Registratie: Mei 2003
  • Laatst online: 30-11 15:27

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

Ik heb eerlijk gezegd al meerdere migraties gedaan met de ADMT en eigenlijk nog nooit problemen gehad.

Als je migreert met behoud van sid-history werkt toegang tot nog niet gemigreerde servers ook nog gewoon. Mookie heeft in het verleden eens gepost over de ADMT in combinatie met een trust waar sid-filtering op enabled was, en in dat specifieke geval bleek de sid-history niet te werken. Maar da's logisch, op de trust staat immers ingesteld dat enkel bepaalde sid's over de trust mogen..

Lees nu gewoon de bovenstaande link even door. :)

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B


  • Semt-x
  • Registratie: September 2002
  • Laatst online: 29-11 14:41
Ook ik heb prima ervaringen met ADMT, vele duizenden machines/servers en users probleemloos gemigreerd sinds de release van windows 2000.
mookie's advies is gebaseerd op een post die hij eerder deed, waaruit bleek dat hij essentiele dingen van het migratie proces niet wist en dus nu met krom voorstel komt.
optie1: Ik vind dat iemand die dat publiekelijk voorstelt direct uit zijn functie moet worden ontheven.
optie2: ADMT kan weldegelijk gefaseerd migreren en is 100% supported.

Mijn advies: ADMT is precies de tool die je nodig hebt, het is gemaakt voor een situatie als deze. Onderzoek de werking van ADMT in een test omgeving, als daar geen tijd voor is roep mensen met ervaring op die je in dat traject begeleiden.

h2h,
Sem

  • mookie
  • Registratie: Juni 2002
  • Laatst online: 15-06 08:37

mookie

Heerlijk Helder

ADMT is zeker geschikt om domeinen op te splitsen, echter wordt het door microsoft niet ondersteund.
Ik weet ook niet waarom niet want het werkt verders prima.
Letterlijk uit de ADMT guide op pagina 10:

Splitting or cloning forests—for example, to accommodate divestiture of an organization—is not supported. For more information, see Restructuring Limitations (http://go.microsoft.com/fwlink/?LinkId=121736).

Dus niet ondersteund, maar verders werkt het prima.

Overigens dat ene topic dat ik heb over DLG's heeft niet zozeer te maken met het niet snappen van het migratie process... een gefaseerde interforest migratie terwijl sid quarantine actief is is gewoon niet mogelijk.
Mijn vraag was niet waarom sid history niet werkt... mijn vraag was hoe ik een oplossing bouw zonder gebruik te maken van sid history.
Blijkbaar een situatie waar niemand zich ooit in heeft begeven... ik snap heel goed wat wel en niet kan, ik vroeg me alleen af wat anderen in zo'n situatie ooit hebben gedaan...

"waaruit bleek dat hij essentiele dingen van het migratie proces niet wist en dus nu met krom voorstel komt."
Pfffff.....

Maar goed, vast 1 tip, aangezien dat in jouw situatie wel kan:
Op je trust moet je sid quarantine uitzetten en sid history aanzetten.

met dit kun je de stand bekijken:
netdom trust <sourcedomeinnaam> /domain:<targetdomeinnaam> /quarantine
netdom trust <sourcedomeinnaam> /domain:<targetdomeinnaam> /EnableSIDHistory

Quarantine staat als het goed is aan, en SID history is als het goed is disabled.

Dus deze commando's draaien:
netdom trust <sourcedomeinnaam> /domain:<targetdomeinnaam> /quarantine:no
netdom trust <sourcedomeinnaam> /domain:<targetdomeinnaam> /EnableSIDHistory:yes

Doe dat, en dan kun je gefaseerd uitmigreren.

mookie


  • Question Mark
  • Registratie: Mei 2003
  • Laatst online: 30-11 15:27

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

Heren, probeer het even ontopic te houden. Zaken op de man spelen is niet nodig. :)

Topicstarter moet even duidelijk maken wat hij precies wil:
  • Moet het bestaande domein gesplitst worden? (dat wil zeggen het bestaande domein intact houden op twee niet verbonden lokaties)
  • Moeten er een aantal systemen/users/werkplekken uit het bestaande domein gemigreerd worden naar een compleet nieuw op te bouwen domein.
Het eerste punt is zoals Mookie al aangeeft niet supported. Zoals ik de topicstarter begrijp wil topicstarter de tweede optie, en daar is de ADMT de perfecte tool voor.

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B


Verwijderd

Topicstarter
Heren, dank voor jullie reacties. _/-\o_
Question Mark schreef op vrijdag 16 december 2011 @ 08:12:
  • Moet het bestaande domein gesplitst worden? (dat wil zeggen het bestaande domein intact houden op twee niet verbonden lokaties)
  • Moeten er een aantal systemen/users/werkplekken uit het bestaande domein gemigreerd worden naar een compleet nieuw op te bouwen domein.
1. Het bestaande domein moet inderdaad intact worden gehouden, dus geen enkele rol of service moet daar 'uitgefaseerd' of gewijzigd worden.
2. Er moet een selectie (dus niet alle!) systemen/gebruikers/werkplekken uit het bestaande domein worden gemigreerd naar een nieuw te installeren domein.

Ik zal me eens verdiepen in de ADMT-tool.

  • Semt-x
  • Registratie: September 2002
  • Laatst online: 29-11 14:41
goed bezig!

Maak een nieuw domein aan voor het "nieuwe" bedrijf en migreer alleen de objecten van het oude naar het nieuwe domein.
Zorg dat sidhistory aan staat, zodat accounts uit het nieuwe domein, zonder aanpassingen in het oude domein resources daar kunnen benaderen.

Wat je ook doet, knip het domein niet in tweeen, hoewel je het in eerste instantie werkend krijgt zjin de gevolgen groot voor de toekomst als Exchange / Lync of Federation Services geconfigureerd moet worden,
al kan dat pas over 10 jaar zijn.
De kans is dan groot dat er een specialist moet komen, dat is altijd ongeplanned, waar de baas verdrietig van wordt omdat die specialisten niet de goedkoopste zijn.
Daar spreek ik uit ervaring, dat soort ellende oplossen is mijn werk. Vandaar de ongemeen felle reactie in mijn vorige post. De baas is het slachtoffer van dat soort creatieve uitspattingen.
Pagina: 1