Migrering Tenant A -> Tenant B​

Tenant A vil være kilden eller den opprinnelige Tenanten som vi migrerer fra .

Tenant B vil være målet, eller destinasjonsleieren som vi migrerer til .

Vi vil anta følgende om Tenant A:

• Brukere har en minimumslisens for Intune og Azure AD Premium P1

• Enheter er registrert i Autopilot

• Enhetene er koblet til Azure AD (ikke lokal Active Directory koblet til)

• Enheter er registrert i Intune

Nå med enhver migrering, må en faktisk migrering skje. La oss ta følgende antagelser om den migreringen:

• Nye identiteter er opprettet for brukere i Tenant B

• Brukerdata er iscenesatt og overført til Tenant B

Vi vil da anta følgende om Tenant B:

• Brukere har en minimumslisens for Intune og Azure AD Premium P1

• Intune er konfigurert til å støtte de ønskede konfigurasjonene, applikasjonene og policyen for å støtte enheter

Oppgaver?

Med forutsetningene på plass, la oss bryte ned hvordan prosessen fungerer. Som de fleste kule ting med Intune, gjennomfører vi migreringen med en serie skript. Her er oversikten på høyt nivå over hvordan vi utfører migreringen:

1. Migreringsapppakke (.intunewin) gjøres tilgjengelig for brukere via Intune Company Portal.

2. Brukeren installerer migreringsappen

3. Applikasjonen pakker ut serier med skript til den lokale PC-en og begynner å kjøre det primære PowerShell-skriptet som utfører følgende:

   • Autentiserer til Tenant A ved hjelp av Microsoft Graph API med appregistrering

   • Samler inn enhetsinformasjon fra Tenant A

   • Kopier %APPDATA% og %LOCALAPPDATA% til et midlertidig sted

   • Fjern tidligere MDM-registreringer fra registeret

   • Oppgaver etter fase etter migrering

   • PC forlater Azure AD fra Tenant A

   • Intune-objekt slettet fra Tenant A

   • Autopilotobjekt slettet fra Tenant A

4. Brukeren blir bedt om at de vil bli logget av om 1 minutt.

5. Enheten starter på nytt, og starter deretter på nytt etter 30 sekunder

6. Bruker logger på med Tenant B-legitimasjon

7. PC er Azure AD sluttet og Intune registrert til Tenant B

8. Oppgaven kjører for å gjenopprette %APPDATA% og %LOCALAPPDATA% elementers nye profil

9. Autentiser til Tenenat B ved hjelp av Microsoft Graph API med appregistrering

10. Oppgaven kjører for å angi den primære brukeren av enheten i Intune

11. Oppgaven kjører for å migrere BitLocker-nøkkelen til Tenant B Azure-miljøet

12. Oppgaven kjører for å registrere enheten i Tenant B-autopilot med Group Tag-attributt fra Tenenat A

Hva trengs?

Så hva trenger du for å gjøre dette? Vel, her er individuelle deler vi skal dekke i de neste innleggene:

1. App-registreringer : App-registreringer opprettes i både Tenant A og Tenant B. Dette vil være den primære metoden for å autentisere objekter gjennom de ulike skriptene som brukes i prosessen.

2. Skript : Det er flere skript som brukes under prosessen som må endres for organisasjonsspesifikke verdier som appregistreringsinformasjon, Tenant-ID-er, autopilotgruppetagger osv.

3. Juster XML-oppgaver til PowerShell-skript : PowerShell-skriptene kjøres på forskjellige kontekstnivåer, men de fleste er som SYSTEM eller NT\AUTHORITY. For å oppnå dette, vil hvert PowerShell-skript ha en tilhørende XML-fil for å angi en planlagt oppgave i Windows som kjører skriptet med riktig kontekst. Det er også ganske mye sekvensering, så oppgavene vil tillate oss å angi de riktige tidsintervallene vi vil at hvert stykke skal kjøre på, både før og etter migrering.

4. Windows Provisioning Package : Dette er kjernen i hele prosessen. Vi bruker Windows Configuration Designer- verktøyet til å lage en .PPKG-fil, som brukes til å levere et Azure AD Bulk Primary Refresh Token (BPRT). Pakken er det som binder enheten til Tenant B etter å ha blitt fjernet fra Tenant A

5. Opprydding : Som jeg sa, det er pre- og post- elementer til migreringen, og de må sekvenseres nøye. Skriptene våre sikrer at Intune- og Autopilot-objekter i Tenant A blir slettet til riktig tid for å tillate registrering og registrering til Tenant B.

6. Å bruke virtuelle maskiner (VM) for å teste denne prosessen er kritisk. Sørg for at du har flere VM-er å teste med og 1 eller 2 kontoer i Tenant A som har en motpartsidentitet i Tenant B. Denne testingen er også et flott tidspunkt for å dokumentere sluttbrukeropplevelsen, som er avgjørende for hele operasjonen.