[2003] Offline AD users/groups migratie.

[D3NN1S]

Alaaf!

Momenteel loop ik tegen een groot vraagstuk aan.
Ik heb op regelmatige basis users/groups migraties gedaan van domein X naar domein Y.
Vaak gebruikte ik hierbij tools zoals ADMT of Quest migration manager welke netjes naar beide domeinen connecteerd en de users incl SID historie, groupmembership etc. migreerd.

Maar nu,

Binnenkort komt er een migratie aan waarbij beide domeinen onder geen beding met elkaar mogen praten!
Er mag dus geen trust tussen de twee domeinen gelegd worden of een connectie naar beide kanten vanaf een quest/admt server.
Toch willen we zo makkelijk mogelijk alle users vanaf domein X incl passswords, groupmembership, SID historie, exchange attributes etc. naar domein Y migreren!

Het halve internet is al afgespeurd en er is zelfs een idee geopperd om een domeincontroller van domein X onder de arm mee te nemen naar Y en dan de migratie te doen. (Dit gaat om verschillende redenen niet lukken). Maar tot nu toe hebben we nog geen goede manier gevonden.

Wij hebben volledige toegang tot domein X en Y maar ze mogen gewoon niet met elkaar babbelen.
Heeft er al eens iemand eerder met dit bijltje gehakt? en is er een mogelijkheid om alles bijv. te exporteren naar een DB/File en te importeren op het nieuwe domein incl behoud van bovenstaande?

Alle hulp is welkom!

PS: het gaat in dit geval om twee windows 2003 domeinen.

[Remco]

Kan dat niet gewoon met ADMT ?

[Semt-x]

Wat wil je met sidhistory bereiken, zonder trust?

[Question Mark]

Gewoon met csvde een export maken, die bewerken en weer importeren?

How to use Csvde to import contacts and user objects into Active Directory
CSVDE - Examples Import Export of user accounts Active Directory

[D3NN1S]

Semt-x schreef op donderdag 02 februari 2012 @ 18:26:
Wat wil je met sidhistory bereiken, zonder trust?

Alle servers van domein X gaan ook over naar domein Y. We willen niet alle security groepen en rechten/permissies opnieuw instellen.
Het gaat om een source domein met ruim 900 gebruikers/groepen en een stuk of 30 servers.

Question Mark schreef op donderdag 02 februari 2012 @ 19:25:
Gewoon met csvde een export maken, die bewerken en weer importeren?

How to use Csvde to import contacts and user objects into Active Directory
CSVDE - Examples Import Export of user accounts Active Directory

Dat is helaas geen oplossing, dan neem ik de sid history en passwords niet mee.
Dan moeten we daarna iedere groep opnieuw configureren en alle file/app permissies gaan vervangen.

Remco schreef op donderdag 02 februari 2012 @ 17:27:
Kan dat niet gewoon met ADMT ?

Nee ADMT werkt alleen als je met beide domeinen kan connecten. Zoals in de TS uitgelegd is dit dus niet het geval helaas
(Stomme amerikaanse security officers!! Grrrr!! ) /rant

[SteeringWheel]

Dan met csvde exporteren en importeren en de sidhistory scripten

[D3NN1S]

SteeringWheel schreef op vrijdag 03 februari 2012 @ 11:18:
Dan met csvde exporteren en importeren en de sidhistory scripten

Leuk antwoord maar hoe en met wat had je dat in gedachte dan?

[SteeringWheel]

D3NN1S schreef op vrijdag 03 februari 2012 @ 11:33:
[...]
Leuk antwoord maar hoe en met wat had je dat in gedachte dan?

Hoe en wat snap je niet dan? Als je de sid van de oude user exporteert kun je die gewoon in het sidhistory attribuut van de nieuwe gebruiker weer opslaan.

[Question Mark]

D3NN1S schreef op vrijdag 03 februari 2012 @ 11:33:
[...]


Leuk antwoord maar hoe en met wat had je dat in gedachte dan?

Denk dat je hier wel wat mee moet kunnen:

PowerShell Module for Working With AD SID History

[Semt-x]

SteeringWheel schreef op vrijdag 03 februari 2012 @ 12:09:
[...]

Hoe en wat snap je niet dan? Als je de sid van de oude user exporteert kun je die gewoon in het sidhistory attribuut van de nieuwe gebruiker weer opslaan.

onzin, als je het sidhistory veld wilt beschrijven moet je aan een aantal voorwaardes voldoen. Het is geen gewoon property veld zoals bijv phone. de details:
MSDN: Using DsAddSidHistory

Als de domeinen elkaar niet trusten, heb je overigens niets aan sidhistory. Het biedt alleen een uitkomst voor migratie scenario's, dit is voor zover ik het begrijp een split scenario.

Het exporteren van gebruikers gegevens en importeren van die gegevens in het nieuwe domein is dan de optie. Echter moet je dan wachtwoorden exporteren, als het uberhaupt al kan. (natuurlijk niet , zou je zeggen)
daarnaast moet je alle rechten opnieuw instellen.

Het kiezen van het meest geschikte scenario is in mijn ogen geen technisch vraagstuk. De vraag kan alleen beantwoord worden als de geschiedenis en alle in en outs van dit scenario bekend zijn. niet iets voor een technisch forum imo.

h2h,
Sem

[D3NN1S]

Semt-x schreef op vrijdag 03 februari 2012 @ 13:16:
[...]
<knip>

Als de domeinen elkaar niet trusten, heb je overigens niets aan sidhistory. Het biedt alleen een uitkomst voor migratie scenario's, dit is voor zover ik het begrijp een split scenario.

Zoals al eerder gemeld is dit daadwerkelijk een migratie naar een ander domein.
Dus alle gebruikers/groepen en ook resources verhuizen mee naar het andere domein.

(Het is een losstaande vestiging die nu aan het europesche domein gekoppeld moet worden, MAAR omdat er op het oude domein externen partijen toegang hebben mogen we deze domeinen niet met elkaar laten praten tijdens de migratie. Uiteindelijk gaat alles over in het europesche domein ook hun servers e.d. en hebben we dus daadwerkelijk de SID history nodig van de gebruikers om te voorkomen dat we alles opnieuw moeten in gaan stellen.)

Zie het dus als een volledige ADMT/Quest migration manager migratie. Alles moet over. Useraccounts, computeraccounts, groups, groupmemberships, SID historie, profielen etc etc. Alleen dan zonder een trust/communicatie tussen de domeinen.

Overigens zijn de genoemde voorstellen niet echt funtioneel. Om de rede die Semt-x al aanhaalt en om de rede dat ik dan nog de group memberships e.d. mis.
Ik had gewoon gehoopt dat er een Export all -> import all prog bestond die ook de translation doet van domein X naar domein Y. Opzich moet dat technisch haalbaar zijn alleen hoe is de grote vraag nog steeds

[ Voor 24% gewijzigd door D3NN1S op 03-02-2012 14:02 ]

[Semt-x]

Enige optie die ik zie is het de oude omgeving opbouwen door het restoren van backups en dan een migratie te doen.

h2h,
Sem

[D3NN1S]

Najaaa er is een andere optie, voor diegene die ooit dit topic lezen en er mee te maken krijgt.
Wat je KAN doen is een DC inrichten op het oude domein na de DC promo koppel je hem los.
Vervolgens clean je de AD metadata op en neemt hem mee naar het nieuwe domein.
Daar Seize je dan alle FSMO rollen (hij staat toch los van het oude domein) en leg je een trust tussen die DC en het nieuwe domein. Vervolgens kan je met ADMT/Quest een normale migratie doen.
(Daarna noooit meer deze DC aan het oude domein koppelen overigens!! )

Echter gaat dit traject over een paar maanden lopen, het zijn namelijk iets van 15 vestigingen of iets dergelijks.
Als we dit iedere keer moeten doen per vestiging kost dit erg veel tijd. (want er wijzigd iedere dag wel wat in de AD dus is de migratie nooit "vers" )
Vandaar dat ik hoopte met dit topic een makkelijkere manier te vinden dan deze.
Ik had de hoop op een soort migratie tool met een export -> convert -> import functionaliteit maar deze lijkt dus niet te bestaan.

[ Voor 8% gewijzigd door D3NN1S op 03-02-2012 14:30 ]

[Semt-x]

is zelfs een idee geopperd om een domeincontroller van domein X onder de arm mee te nemen naar Y en dan de migratie te doen. (Dit gaat om verschillende redenen niet lukken).

Wat je KAN doen is een DC inrichten op het oude domein na de DC promo koppel je hem los.
Vervolgens clean je de AD metadata op en neemt hem mee naar het nieuwe domein.

Dat was toch geen optie?

De technische opties zijn beperkt, vandaar het afschrijven van die ene optie (mag geen trust dus geen ADMT) grote gevolgen heeft voor de hoeveelheid werk en dus de kosten.
Het wordt een sommetje maken en bespreken met de beslissers. Eerst uitleg wat een trust precies is, en welke gevolgen het heeft. Daarna de vraag of het ze waard is dat een trust vrije oplossing, die x EUR meer kost.

h2h,
Sem

[ Voor 0% gewijzigd door Semt-x op 04-02-2012 13:27 . Reden: grammatica incorrectica ]

[SteeringWheel]

hier stond waarschijnlijk onzin

[ Voor 88% gewijzigd door SteeringWheel op 03-02-2012 20:54 ]