Innledning
Etter å ha diskutert i de første artiklene i denne serien noen av de generelle hensyn som er involvert i noen form for Active Directory omstillingsprosjekt og også begrensningene ved bruk ADMT for å utføre skog eller domene migrasjoner eller konsolideringer, vi nå kommer til å gå videre til å diskutere noen spesielle problemer knyttet til å bruke ADTM selv. Disse problemene er alle ting du bør være oppmerksom på under planleggingen av migrasjon eller konsolidering prosjektet, og underveis vil jeg bli inkludert ulike tips og peker ut noen feller forbundet med å bruke ADMT for Active Directory Migreringer /konsolideringer.
Merk at emnene som følger i denne artikkelen, og de neste artiklene er i ingen spesiell rekkefølge. Forhåpentligvis noen av problemstillingene vil være til hjelp for deg når du planlegger og gjennomføre din egen Active Directory omstillingsprosjekt.
Hvilke først, konsolidere eller oppgradere?
La oss si at Active Directory infrastruktur består av to skoger som kjører Windows Server 2008 R2. Målet ditt er å modernisere og forenkle infrastrukturen for å gjøre den kraftigere og enklere å administrere. For å oppnå dette målet du ønsker å utføre to oppgaver:..
Oppgrader dine domenekontrollere til Windows Server 2012 R2
Spørsmålet du nå står overfor er dette: Skal du begynne med å konsolidere to Windows Server 2008 R2 skoger til en enkelt Windows Server 2008 R2 skog og deretter oppgradere at skogen til Windows Server 2012 R2 Active Directory? Eller skal du gjøre det den andre veien rundt dvs. start ved å oppgradere både Windows Server 2008 R2 skoger til Windows Server 2012 R2 Active Directory og deretter konsolidere de oppgraderte skoger til en enkelt Windows Server 2012 R2 skogen?
I andre ord , som bør du først: konsolidere skoger eller oppgradere dem til de nyere versjoner av Active Directory
Figur 1: Samle først deretter oppgradere vs. oppgradere først deretter konsolidere
.
Svaret er ganske enkelt å utlede fra antall trinn i hver del av diagrammet over. Med andre ord, bør du begynne med å konsolidere en skog inn i den andre skogen, deretter oppgradere din gjenlevende skog til den nye versjonen av Active Directory. Det gir ikke mening å oppgradere skogen fordi det er unødvendig ekstra arbeid for å gjøre det.
SID historie og ADMT
Når du oppretter en ny brukerkonto i Active Directory, sikkerhetsidentifikatoren ( SID) for kontoen lagres i objectSID egenskap av objektet representerer konto i Active Directory. En 128-bit globalt unik identifikator (GUID) også er tilordnet objektet, og denne GUID er lagret i attributt objectGUID av objektet. Internt bruker Active Directory GUID stedet for SID for å identifisere stedene. Det er fordi GUID aldri endres, men SID kan endre seg. For eksempel når en brukerkonto flyttes fra et domene til et annet, SID endringer. Active Directory-poster hvordan SID endringer for en konto i det som kalles den SID historie for kontoen, som er lagret i sidHistory egenskap av objektet. Hvis du ønsker å lese mer bakgrunnsinformasjon om hvordan alt dette ble til, se denne linken.
Når du flytter brukerkontoer i et Active Directory migrasjon eller konsolidering, kan du enten bruke SID historie eller ikke bruke den for å utføre overføringen. For informasjon om hvordan du overfører kontoer mens du bruker SID historie, se denne linken. Og for å få informasjon om migrering kontoer uten å bruke SID historie, se denne linken.
Noen ganger under en migrering må du kanskje eksportere eller importere sidHistory attributter eller legge til eller fjerne dem til /fra konto stedene. Selv om du kan utføre slike handlinger ved hjelp ADMT, kan det være rotete å prøve og gjøre det. Heldigvis viser det seg at du kan også bruke Windows Powershell til å gjøre denne typen ting, og den regjerende ekspert på dette temaet er Ashley McGlone, en Premier Feltet Engineer (PFE) hos Microsoft som spesialiserer seg på Active Directory og Windows Powershell. Ashley har utviklet en Windows Powershell-modul kalt SIDHistory Module som gir deg innsyn i status for SID historie gjennom Active Directory-skogen, hjelper deg å oversette SID historie til NTFS ACL, og enkelt målrette SID historie fjerning. Den SIDHistory Powershell-modulen kan lastes ned fra TechNet Gallery og du kan finne alt fra Ashley blogginnlegg på temaet SID historie på her.
Migrering lokale brukerkontoer
Her er en interessant scenario som én konsulent fortalte meg at han hadde møtt. Kunden hadde en driftskritisk server som kjører Windows Server 2003, og ønsket å migrere alle de lokale brukerkontoer fra denne serveren til en ny server som kjører Windows Server 2012 R2. Det interessante er at den gamle serveren var en frittstående server i en arbeidsgruppe dvs. det ikke ble sluttet til en Active Directory-domene. Kunden har et Active Directory infrastruktur, det er bare at denne serveren ikke var koblet til den.
Dette medførte noen interessante problemer, så konsulenten søkte TechNet for noen svar og kom opp med følgende artikkel i TechNet Wiki:
Overføre Lokale brukere og amp; Grupper fra Windows Server 2003 til 2008 R2 med Windows Server Migration Tools
Server Migration Tools beskrevet i artikkelen ovenfor er fem Windows Powershell cmdlets som først ble introdusert i Windows Server 2008 R2 for å forenkle jobben med å migrere serverroller og funksjoner fra tidligere Windows Server-versjoner til Windows Server 2008 R2. Du kan finne mer informasjon om disse verktøyene her. Det er også en 600 + side eBok tilgjengelig som en gratis nedlasting i PDF-format som forklarer hvordan man kan overføre serverroller og funksjoner til Windows Server 2012 eller Windows Server 2012 R2 tilgjengelig fra TechNet Wiki.
Anyways, konsulenten var til slutt i stand til å utføre overføringen at kunden forespurt, men gjorde det bare etter første forsøk på å overbevise kunden å følge en annen tilnærming som innebærer først å opprette en ny Active Directory-miljøet fra den gamle serveren og deretter bruke ADMT å fusjonere den nyopprettede domene inn kundens eksisterende domene. Her er fremgangsmåten at konsulenten foreslåtte kunden bør følge:
- Neste du vil skape et tillitsforhold mellom den midlertidige domene og kundens produksjon domene.
Du vil nå bruke ADMT å migrere domenebrukerkontoer fra den midlertidige domenet til produksjon domene. Du må bruke ADMT selvfølgelig fordi de midlertidige og produksjons domener tilhører forskjellige skoger. Følg instruksjonene i Active Directory Migration Tool (ADMT) Guide for å migrere regnskapet mellom de to skoger. Nok en gang, kan du laste ned denne guiden fra denne linken.
- Når brukerkontoer er flyttet fra den midlertidige domenet til det nye domenet, må du overføre eventuelle forretningsdata fra den gamle Windows Server 2003 server til nye Windows Server 2012 R2 server som du har utplassert i produksjon domene.
Når alle brukerkontoer og data har blitt migrert ut av den gamle serveren, kan du kjøre dcpromo på den igjen for å degradere det fra en domenekontroller til en frittstående server på nytt og deretter sende den til pensjonsalder.
Legg merke til at denne prosessen ikke bare vandrer brukerkontoene, men også passordene for disse kontoene, noe som (så vidt jeg vet ) den annen tilnærming (ved hjelp av Server Migration Tools) ikke la deg gjøre. Denne sistnevnte tilnærmingen gjør mye mer fornuftig, men dessverre kunden valgte å gå i stedet med den tidligere tilnærming. Den gode nyheten er selvfølgelig at konsulenten fikk betalt uansett. Anmeldelser
Next Page:Powershell Essentials (del 4)
Begynn med å kjøre dcpromo på den frittstående Windows Server 2003 server for å lage en ny "midlertidig" Active Directory-skogen ved å fremme serveren til rollen av en domenekontroller i en ny skog. Hvis du har glemt hvordan du gjør dette kan du ta en titt på denne artikkelen. Resultatet av dette er at den lokale kontoen database på den frittstående serveren vil bli Active Directory databasen, slik at alle de lokale brukerkontoer på serveren er nå domenebrukerkontoer i den midlertidige domenet.