September 18, 2020
  • 11:10 pm Microsoft 365 – Salasanan resetointi itsepalveluna (SSPR)
  • 9:12 pm Exchange Online – Roskapostin estäminen top-level domainin (TLD) perusteella
  • 11:26 pm Windows 10 – Fiddler Web Debugger Proxyn asennus ja käyttöönotto
  • 3:00 am Microsoft 365 -käyttäjätilin kaappaamiseen reagointi – Tilanteen normalisointi
  • 12:40 am Microsoft 365 -käyttäjätilin kaappaamiseen reagointi – Tilin turvaaminen

Johdanto:

Käyn tässä kirjoituksessa läpi Windows 10 -käyttäjäprofiilin migraation uudelle käyttäjätilille samalla tietokoneella Azure AD -tenanttimuutoksen yhteydessä. Käytän toimenpiteeseen Microsoftin omaa User State Migration Tool -työkalua (USMT). Käyttäjäprofiilin migraatiolla tarkoitan seuraavien tietojen talteenottoa ja siirtoa:

  • Käyttäjän kotihakemiston C:\Users\%username%\ alikansiot ja tiedostot
  • Rekisterin käyttäjäkohtaiset asetukset käyttöjärjestelmästä ja sovelluksista  (NTuser.dat-tiedosto, joka ladataan kirjautumisen yhteydessä rekisterin avaimeen HKEY_CURRENT_USER)

Toteutan migraation niin sanottuna hard-link -migraationa. Tämä tarkoittaa sitä, että toimenpiteet tapahtuvat saman laitteen sisällä, eikä migratoitavaa dataa missään vaiheessa poistu laitteen ulkopuolelle. Näin vältetään ylimääräisen tallennustilan tarve ja tiedostojen kopioiminen, kun tiedostoja ei heti siirretä vanhasta tallennussijainnista uuteen. Sen sijaan vanhassa käyttäjäprofiilissa oleville tiedostoille luodaan ns. hard-link -migraatio-varastoon ylimääräiset tiedostopolut, joihin referoidaan migraation aikana. Migratoitavilla tiedostoilla tulee siis olemaan kaksi tiedostopolkua, jotka molemmat viittaavat samaan kohdetieodstoon. Lopulta hard-link -migraatio-varasto voidaan poistaa vaikuttamatta vanhan tai uuden käyttäjäprofiilin tiedostoihin.

Profiilien migraatioon löytyy myös kolmannen osapuolen työkaluja, joissa tulee mukana graafinen käyttöliittymä (mm. ProWiz ja USMTGUI). USMT on kuitenkin Microsoftin suosittelema ja ylläpitämä ratkaisu, johon pääosin muut kolmannen osapuolen työkalut perustuvat. Aiemmin oli myös Microsoftin oma Windows Easy Transfer, mutta sen tuki on lopetettu ja työkalu kehitettiinkin jo Windows Vistan aikana. USMT on myös äärimmäisen kustamoitava, skriptattava ja skaalautuu hyvin laajoihin ympäristöihin ja provisiointiskenaarioihin esimerkiksi SCCM:n kanssa.

Milloin käyttäjäprofiilia sitten tulisi migratoida saman tietokoneen sisällä? Yksi tilanne on muutos Microsoft 365 -tenantissa ja Azure AD -liitoksessa. Tällöin Windows 10 tulee luomaan uuden käyttäjäprofiilin, kun käyttäjä kirjautuu uudella käyttäjätunnuksellaan tietokoneelle ensimmäistä kertaa uuden tenantin Azure AD -liitoksen jälkeen. Vanha profiili säilyy kuitenkin samalla koneella ja on siten migratoitavissa. Vastaavasti, jos koneella on aiemmin ollut pelkkä paikallinen käyttäjä, niin käyttäjälle luodaan uusi käyttäjäprofiili Azure AD -liitoksen jälkeen ensimmäistä kertaa kirjauduttaessa Azure AD -tunnuksin. Tällöin paikallisen profiilin data halutaan todennäköisesti migratoida suoraan uudelle käyttäjälle.


Huomioitavaa

Kaikki tässä artikkelissa esittämäni toimenpiteet on testattu vain yhdessä ympäristössä, yhdellä koneella ja kahden käyttäjäprofiilin välillä. Lukija on itse vastuussa esimerkkini soveltamisesta omaan käyttötarkoitukseensa sopivaksi.


Työkalun asennus ja perustoiminta:

USMT on komentorivipohjainen työkalu, joka sisältyy Windows Assessment and Deployment Kit (Windows ADK) -ohjelmapakettiin. Lataus osoitteesta: https://docs.microsoft.com/fi-fi/windows-hardware/get-started/adk-install#winADK

Windows 10:n 1909 versiolle ei tämän kirjoituksen kirjoitushetkellä ole omaa versiota ADK:sta, joten asennetaan Download the Windows ADK for Windows 10, version 1903

Suoritetaan ladattu adksetup.exe -tiedosto ja valitaan asennusohjelmassa valinta “Install the Windows Assessment and Deployment Kit – Windows 10 to this computer“:

Seuraavassa vaiheessa Microsoft pyytää kerätä dataa työkalun käytöstä. Itse kiellän tiedon keruun ja jatkan eteenpäin. Hyväksyin ohjelmiston käyttöehdot, minkä jälkeen pääsin valitsemaan, mitä kaikkea haluan ADK-paketista asennettavan. Osa on jo minulla asennettuna, enkä tarvitse muita tätä kirjoitustani varten, joten valitsin ainoastaan User State Migration Tool (USMT) -vaihtoehdon.

Viimeistelin asennuksen.

Ennen työkalun käyttöä kannattaa ymmärtää sen perustoiminnot. USMT koostuu kolmesta suoritettavasta ohjelmasta:

  • ScanState= Vastaa tietokoneen käyttäjäprofiilien skannauksesta, tiedostojen ja asetusten keruusta sekä migraatio-varaston luomisesta
  • LoadState = Vastaa migratioon sisällytettyjen käyttäjäprofiilien siirtämisestä migraatio-varastosta lopulliseen kohteeseen
  • USMTUtils = Vastaa migraation jälkeisistä siivoustoimista, vianselvityksestä ja virhetarkistuksesta

Noista komennoista keskityn tässä artikkelissa kahteen ensimmäiseen. Lisäksi USMT käyttää tyypillisesti seuraavia neljää .xml-päätteistä konfiguraatiotiedostoa:

  • MigApp.xml = Määrittää, mitä sovellusasetuksia migratoidaan ja miten
  • MigUser.xml = Määrittää, mitä tiedostoja ja profiiliasetuksia käyttäjäprofiilista migratoidaan ja miten (pääasiassa käyttäjän kotihakemiston sisältä tai tiedostopäätteen perusteella)
  • MigDocs.xml = Määrittää, mitä tiedostoja ja profiiliasetuksia käyttäjäprofiilista migratoidaan ja miten (käyttäjän kotihakemiston sisä- tai ulkopuolelta tiedostosijainnin perusteella)
  • Config.xml = Kustomoitava tiedosto, jossa määritetään, mitä tulisi jättää migraation ulkopuolelle

Config.xml on noista ainoa, jota on tarkoitus muokata. Se voidaan generoida valinnaisesti ScanState-ohjelmalla. Tiedostossa voidaan määrittää, mitä komponentteja tai järjestelmäasetuksia tulisi jättää pois migraatiosta. Esimerkki config.xml -tiedoston generoimisesta:

scanstate.exe /genconfig:config.xml /i:migapp.xml /i:migdocs.xml /i:ExcludeSystemFolders.xml /i:MigrateBrowserAppData.xml /o /v:5

Itse en tässä kirjoituksessa käytä config.xml -tiedostoa migratoinnin kustomoimiseen. Käytän sen sijaan kustomoimaani ExcludeSystemFolders.xml -tiedostoa EhlerTechiltä: https://ehlertech.com/customxmls/ sekä tekemääni MigrateBrowserAppdata.xml -tiedostoa. Tarkennan tiedostojen käyttötarkoituksen myöhemmin kirjoitukseni aikana.

Muita kannattaa ajatella valmiina template-tiedostoina, joihin ei kosketa. MigUser.xml ja MigDocs.xml -tiedostoja ei tulisi käyttää samanaikaisesti, vaan ainoastaan toista niistä. Microsoft suosittelee itse mieluummin MigDocs.xml:n käyttöä, sillä se kerää dataa järjestelmästä monipuolisemmin, eikä ole rajoittunut vain tiettyihin tiedostopäätteisiin toisin kuin MigUser.xml. Myös muita konfiguraatiotiedostoja voidaan luoda ja sisällyttää migraatioon halutessa.

Kannattaa kuitenkin pitää mielessä, että käytettävät xml-tiedostot tulee määrittää sekä ScanState että LoadState-vaiheissa. Tämä siksi, että käytettyjä xml-tiedostoja ei sisällytetä migraatio-varastoon (väliaikainen tallennussijainti migratoitaville tiedoille ennen loppusijoituspaikkaa). Molemmat ohjelmat tarvitsevat xml-tiedostot ohjaamaan migraatiotoimia (mitä migratoidaan ja miten) ja siksi ne tulee sisällyttää molempien ohjelmien komentoihin.


Esimerkin migratointitilanne:

Otetaan esimerkkitilanne, jossa olen migratoimassa käyttäjäprofiilia Azure AD -käyttäjältä nimeltä azuread\markuspyhäranta. Käyttäjän organisaatio on tekemässä Azure AD/Microsoft 365 -tenantin migraatiota uuteen tenanttiin. Käyttäjän Windows 10 -tietokone on liitetty vanhaan tenanttiin, jonka Azure AD -liitos tulee katkaista ennen tietokoneen liittämistä uuden tenantin pilvitoimialueeseen.

Mitä sitten tapahtuu käyttäjän vanhalle käyttäjäprofiilille, kun Azure AD -liitos katkaistaan? Sille ei voida enää kirjautua. Azure AD -tiliä ei voida muuntaa paikalliseksi käyttäjätiliksi, ja sen käyttäjäprofiili tulee löytymään Windowsissa tuntemattomana. Profiili ei kuitenkaan poistu, ja sillä on yksilöllinen SID-tunnus, josta se tunnistetaan.

Kun Azure AD -liitos on tehty uuteen tenanttiin, käyttäjälle luodaan uusi käyttäjäprofiili ensimmäistä kertaa kirjauduttaessa käyttäjän uuden tenantin Azure AD -tunnuksella. Windows 10:ssä ei voi olla kahta samannimistä käyttäjätunnusta. Käyttäjätunnus on todennäköisesti sama myös uudessa tenantissa. Tällöin Windows tyypillisesti ottaa Azure AD -tunnuksesta 12 ensimmäistä merkiä, jonka jälkeen tulee alaviiva ja seitsemän satunnaisen merkin muodostama merkkijono (pieniä kirjaimia ja numeroita). Muoto tulee siis todennäköisesti olemaan seuraava:

azuread\markuspyhära_<merkkijono>

Migraation toimenpiteet tiivistettynä

1) Luodaan paikallinen järjestelmävalvojatili, jos ei sellaista ei ole jo olemassa.

      • Tietokoneen hallinta > Paikalliset käyttäjät ja ryhmät > Käyttäjät > Uusi käyttäjä… > …
      • Tietokoneen hallinta > Paikalliset käyttäjät ja ryhmät > Ryhmät > Järjestelmänvalvojat > Ominaisuudet > Lisää > …

2) Katkaistaan Azure AD -liitos: Asetukset > Tilit > Käytä työpaikan tai koulun resursseja > Katkaise yhteys, jolloin syötetään pyydettäessä juuri luodun paikallisen järjestelmävalvojan tunnukset ja käynnistetään tietokone uudelleen.

3) Kirjaudutaan paikallisella järjestelmävalvojatilillä, joka luotiin kohdassa 1) ja ajetaan ScanState korotetuin oikeuksin:

.\scanstate.exe "C:\Users\USMTStore" /o /hardlink /nocompress /i:migapp.xml /i:migdocs.xml /i:ExcludeSystemFolders.xml /i:MigrateBrowserAppData.xml /localonly /ui:S-1-12-1-1426919175-1304152533-3987183276-4051951554 /ue:*\* /progress:"C:\Users\USMTScanStateProgress.log" /l:"C:\Users\USMTScanState.log" /v:5 /c

4) Pysytään paikallisella järjestelmänvalvojan tilillä kirjautuneena ja tehdään Azure AD -liitos uuteen tenanttiin käyttäjän uuden tenantin tunnuksilla: Asetukset > Tilit > Käytä työpaikan tai koulun resursseja > Liitä tämä laite Azure Active Directoryyn

5) Kirjaudutaan ulos paikalliselta järjestelmänvalvojan tililtä, kirjaudutaan sisään käyttäjän uuden tenantin Azure AD -tunnuksella, jolloin tilille luodaan oma Windows-käyttäjäprofiili. Ajetaan LoadState korotetuin oikeuksin:

.\loadstate.exe "C:\Users\USMTStore" /hardlink /nocompress /i:migapp.xml /i:migdocs.xml /i:ExcludeSystemFolders.xml /i:MigrateBrowserAppdata.xml /ui:S-1-12-1-1426919175-1304152533-3987183276-4051951554 /ue:*\* /progress:"C:\Users\USMTLoadStateProgress.log" /l:"C:\Users\USMTLoadState.log" /mu:azuread\markuspyhäranta:azuread\markuspyhära_fetjidl /v:5 /c

6) Kun LoadState on valmis, kirjaudutaan kerran ulos ja kirjaudutaan takaisin käyttäjän uuden tenantin Azure AD -tunnuksella. Kaikkien vanhan tenantin käyttäjäprofiilin asetusten, tiedostojen ja muiden määritysten tulisi nyt olla migratoituna.

7) Varmistetaan huolellisesti ScanStaten ja LoadStaten progress-lokeista, ettei mitään kriittisiä virheitä tapahtunut toimenpiteiden aikana, eikä mitään oleellista ole jäänyt migratoimatta.

8) Kun ollaan varmoja, että kaikki data on varmasti migratoitu, poistetaan manuaalisesti hard-link-varasto sijainnista C:\Users\USMTStore. Migraatio-varaston poistaminen ei poista dataa itse alkuperäisen käyttäjän profiilista, vaan ainoastaan linkitykset tiedostojen alkuperäiseen sijaintiin. Kun on täysin varmaa, että migraation on ollut onnistunut, voidaan alkuperäinen käyttäjäprofiili poistaa halutessa tallennustilan säästämiseksi.

Ohjauspaneeli > Järjestelmä ja suojaus > Järjestelmä > Järjestelmän lisäasetukset > Käyttäjäprofiilit – Asetukset… > valitaan vanha poistettava käyttäjäprofiili > Poista


Migraation toimenpiteet laajemmin kuvattuna

Mitä tuossa siis äsken äsken tehtiin?

1) Paikallisen järjestelmävalvojan luominen

Luotiin paikallinen järjestelmävalvojatili, jotta tietokoneelle voidaan kirjautua Azure AD -liitoksen katkaisemisen jälkeen. Kun liitos on katkaistu, tietokoneelle ei enää voida kirjautua millään Azure AD -tunnuksin. Siksi tarvitaan paikallinen järjestelmävalvojatili tietokoneella, jolla toimenpiteitä tehdään. Itse tein esimerkiksi paikallisen järjestelmänvalvojan “markus“:

Tietokoneen hallinta > Paikalliset käyttäjät ja ryhmät > Käyttäjät > Uusi käyttäjä… > …

Lisäsin tunnuksen paikalliseen “Järjestelmänvalvojat“-ryhmään:

Tietokoneen hallinta > Paikalliset käyttäjät ja ryhmät > Ryhmät > Järjestelmänvalvojat > Ominaisuudet > Lisää > …

Minulla on nyt paikallinen järjestelmänvalvojan tili, jolle voin kirjautua, kun Azure AD -liitos on katkaistu, eikä alkuperäiselle Azure AD -käyttäjälle voida enää kirjautua.

Voimmekin siksi tässä vaiheessa kiinnittää huomiota käyttäjän työpöydän taustakuvaan, pikakuvakkeisiin ja tehtäväpalkkiin. Jos migraatio onnistuu, tulisi työpöytäympäristönkin näyttää samanlaiselta uudella käyttäjäprofiililla.


2) Azure AD -liitoksen katkaiseminen

Katkaistiin Azure AD -liitos: Asetukset > Tilit > Käytä työpaikan tai koulun resursseja > Katkaise yhteys, jolloin syötettiin pyydettäessä juuri luodun paikallisen järjestelmävalvojan tunnukset ja käynnistettiin tietokone uudelleen. Azure AD -liitos katkaistaan, sillä konetta ei voida liittää uuden tenantin Azureen ennen vanhan liitoksen poistamista.

Syötin paikallisen tunnuksen muodossa .\markus. Tämä siksi, että tietokone on vielä tässä vaiheessa Azure AD -liitetty ja Windows tulisi siten etsimään käyttäjääni Azure AD:n identiteettivarastosta. Piste viittaa tähän paikalliseen tietokoneeseen, ja näin Windows ymmärtää, että olen syöttämässä paikallista-, enkä pilvitoimialuetunnusta.

Entä mitä nykyiselle käyttäjäprofiilille tapahtuu toimenpiteen yhteydessä?

Ennen Azure AD -liitoksen katkaisemista, käyttäjäprofiili on käyttöjärjestelmässä muodossa azuread\markuspyhäranta. Tämä voidaan todentaa mm. navigoimalla: Ohjauspaneeli > Järjestelmä ja suojaus > Järjestelmä > Järjestelmän lisäasetukset > Käyttäjäprofiilit – Asetukset…

Sama tieto nähdään vaihtoehtoisesti komentokehotteen (cmd.exe) komennolla:

C:\Users\MarkusPyhäranta>whoami
azuread\markuspyhäranta

Azure AD -liitoksen katkaisun jälkeen käyttäjäprofiili tulee löytymään järjestelmästä pelkällä Secure Identifierilla (SID). Jos nyt tarkastellaan järjestelmän lisäasetuksista Windowsin käyttäjäprofiileja, löytyy sieltä ainoastaan tuntematon käyttäjäprofiili sen paikallisesti luodun käyttäjäprofiilin ohjella.

Tuntemattoman käyttäjätilin SID löytyy kuitenkin Windowsin rekisteristä avaimesta:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Siellä on listattuna kaikki tietokoneen profiilit niiden SID:n perusteella. Tarkastelemalla arvoa “ProfileImagePath” voidaan helposti tunnistaa, onko kyseessä oikea profiili. Eli navigoidaan Rekisterieditori > \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Nyt siis tiedämme, että migratoitavan käyttäjäprofiilin SID on:

S-1-12-1-1426919175-1304152533-3987183276-4051951554

Voimme käyttää tuota SID:tä, kun määritämme ScanState-komennolla, mitä käyttäjäprofiilia ollaan migratoimassa.


3) ScanState

Kirjauduttiin paikallisella järjestelmävalvojatilillä ja ajettiin ScanState. Avattiin PowerShell korotetuin oikeuksin ja mentiin siihen hakemistoon, jossa scanstate.exe -ohjelma sijaitsee. Itse jätin asennussijainnin oletukselle, joten navigoin PowerShellissä:

cd C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\User State Migration Tool\amd64

Ajettiin ScanState seuraavilla valinnoilla:

.\scanstate.exe "C:\Users\USMTStore" /o /hardlink /nocompress /i:migapp.xml /i:migdocs.xml /i:ExcludeSystemFolders.xml /i:MigrateBrowserAppData.xml /localonly /ui:S-1-12-1-1426919175-1304152533-3987183276-4051951554 /ue:*\* /progress:"C:\Users\USMTScanStateProgress.log" /l:"C:\Users\USMTScanState.log" /v:5 /c

Mitä tuo komento siis tekee? Käydään jokainen valinta läpi:

  • scanstate.exe “C:\Users\USMTStore” = Määrittää suorittamani ScanState.exe -ohjelman ja migraatiovaraston, johon migratoitava data normaalisti kopioidaan. Huom! Tässä yhteydessä dataa ei oikeasti kopioida, sillä määrittelen myös /hardlink ja /nocompress -valinnat.
  • /o = Ylikirjoittaa migraatiovarastossa olevan datan ja config.xml -tiedoston, jos ne ovat jo olemassa.
  • /hardlink = Määrittää migraatiovaraston hard-link -varastoksi. Tällöin dataa ei oikeasti kopioda komennossa määritettyyn varastoon, vaan varastoon luodaan hard-linkit alkuperäisiin tiedostoihin. Dataa ei siis kahdenneta tässä vaiheessa ollenkaan.
  • /nocompress = Tämä tarvitaan aina /hardlink -valinnan kanssa. Oletuksena USMT pakkaa datan, mutta hard-link -migraatiossa dataa ei ikinä kompressoida. Käytännössä siksi, että hard-link -migraatiossa luodaan vain linkitys datan alkuperäiseen sijaintiin, jossa se on pakkaamattomassa muodossaan.
  • /i:migapp.xml = Sisällyttää komentoon migapp.xml-tiedoston, joka sisältää sääntöjä siitä, miten sovellusasetuksia tulisi migratoida.
  • /i:migdocs.xml = Sisällyttää komentoon migdocs.xml-tiedoston, joka sisältää sääntöjä siitä, miten tiedostoja ja profiiliasetuksia tulisi migratoida.
  • /i:ExcludeSystemFolders.xml = Sisällytää komentoon ExcludeSystemFolders.xml-tiedoston. Suljen sillä pois kaikki käyttöjärjestelmän tiedostohakemistot, joiden alta en halua mitään migratoitavan. Olin jo valmiiksi siirtänyt tiedoston samaan hakemistoon. Tiedoston sisältö:
<?xml version="1.0" encoding="UTF-8"?>
<migration urlid="http:\\www.usmtgui.com/migration/1.0/migxmlext/ExcludeSystemFolders.xml">

<!-- This is a modified version of ExcludeSystemFolders.xml by EhlerTech: https:\\ehlertech.com/customxmls/. Modified on 21.5.2020 by Markus Pyhäranta. -->

    <_locDefinition>
		<_locDefault _loc="locNone"/>
		<_locTag _loc="locData">displayName</_locTag>
    </_locDefinition>
    <component type="Documents" context="UserAndSystem" id="documents"> 
        <displayName>ExcludeSystemFolders</displayName> 
        <role role="data"> 
            <rules> 
                <Exclude> 
                    <objectSet /> 
                </Exclude> 
                <unconditionalExclude> 
                    <objectSet>
			<pattern type="File">C:\boot\* [*]</pattern>
                        <pattern type="File">C:\_SMSTaskSequence\* [*]</pattern>
                        <pattern type="File">C:\WINDOWS.old\* [*]</pattern>
                        <pattern type="File">C:\WINDOWS.old.*\* [*]</pattern>
                        <pattern type="File">C:\SWSetup\* [*]</pattern>
                        <pattern type="File">C:\MININT\* [*]</pattern>
                        <pattern type="File">C:\ [prot_ins.sys]</pattern>
			<pattern type="File">C:\ProgramData\* [*]</pattern>
			<pattern type="File">C:\Program Files\* [*]</pattern>
			<pattern type="File">C:\Program Files (x86)\* [*]</pattern>
			<pattern type="File">C:\Quarantine\* [*]</pattern>
			<pattern type="File">C:\PerfLogs\* [*]</pattern>
			<pattern type="File">C:\MSOCache\* [*]</pattern>
			<pattern type="File">C:\Dell\* [*]</pattern>
			<pattern type="File">C:\Intel\* [*]</pattern>
			<pattern type="File">C:\Windows\* [*]</pattern>
			<pattern type="File">C:\DRIVERS\* [*]</pattern>
			<pattern type="File">C:\Recovery\* [*]</pattern>
			<pattern type="File">C:\Windows10Upgrade\* [*]</pattern>
			<pattern type="File">C:\$GetCurrent\* [*]</pattern>
			<script>MigXmlHelper.GenerateDrivePatterns ("* [*.tmp]", "Fixed")</script>
                    </objectSet> 
                </unconditionalExclude> 
            </rules> 
        </role> 
    </component>
</migration>
  • /i:MigrateBrowserAppData.xml = Sisällytää komentoon MigrateBrowserAppData.xml-tiedoston. Sisällytän sillä migraatioon kaikki tiedostot ja alikansiot Google Chrome ja Mozilla Firefox -selainten profiilihakemistoista, joiden alta haluan migratoitavan mm. kirjanmerkit, tallennetut salasanat ja niin edelleen. Olin jo valmiiksi siirtänyt tiedoston samaan hakemistoon. Tiedoston sisältö:
<?xml version="1.0" encoding="UTF-8"?>
<migration urlid="https://markuspyharanta.com/2020/05/22/windows-10-kayttajaprofiilin-migraatio-azure-ad-tenanttimuutokset-yhteydessa-usmt/">
  <component context="UserAndSystem" type="Application">
    <displayName>MigrateBrowserAppData</displayName>
    <role role="Settings">
      <rules context="User">
        <include>
          <objectSet>
            <pattern type="File">%CSIDL_LOCAL_APPDATA%\Google\Chrome\User Data\* [*]</pattern>
            <pattern type="File">%CSIDL_APPDATA%\Mozilla\Firefox\Profiles\* [*]</pattern>
          </objectSet>
        </include>
      </rules>
    </role>
  </component>
</migration>
  • /localonly = Määrittää, että migraatioon kuuluu vain paikallisia tiedostoja. Mitään tiedostoja ulkoisilta tallennusmedioilta, kuten USB-muistitikuilta tai verkkoasemilta ei migratoida.
  • /ui:S-1-12-1-1426919175-1304152533-3987183276-4051951554 = Määrittää migratoinnin piiriin kuuluvat käyttäjäprofiiit, eli tässä tapauksessa vain käyttäjäprofiilin “S-1-12-1-1426919175-1304152533-3987183276-4051951554”
  • /ue:*\* = Määrittää migratoinnin piiriin kuulumattomat käyttäjäprofiilit, eli tässä tapauksessa aivan kaikki käyttäjäprofiilit huolimatta toimialueesta ja sijainnista. Valinta /ui voittaa aina, jos sen ja /ue -valinnan kanssa tulee ristiriita. Esimerkiksi profiili “S-1-12-1-1426919175-1304152533-3987183276-4051951554” on nyt sekä sisällytetty migraatioon että jätetty sen ulkopuolelle. /ui -valinta kuitenkin ottaa prioriteetin, joten se sisällytetään ja kaikki muut jätetään pois.
  • /progress:”C:\Users\USMTScanStateProgress.log” = Määrittää valinnaisen progress-lokin sijainnin hakemistoon C:\Users\USMTScanStateProgress.log. Sisältää mm. virheilmoitukset.
  • /l:”C:\Users\USMTScanState.log” = Määrittää ScanState-lokin sijainnin hakemistoon C:\Users\USMTScanState.log. ScanState-loki generoidaan aina komennon ajamisen yhteydessä oletuksena, mutta tällä voidaan määrittää sen tallennussijainti.
  • /v:5 = Määrittää lokitettavien tietojen tason, eli mitä halutaan lokitettavan ScanState-ohjelman toimista.
  • /c = Määrittää, että ScanState-komento tulee ajaa loppuun, vaikka virheilmoituksia tulisikin. Virheiden merkityksellisyys on jälkeenpäin arvioitavissa lokitiedoista.

Komennolla siis käytännössä määritettiin, mitä migratoidaan, miltä käyttäjäprofiililta ja mihin migraatio-varastoon. Siinä ei määritellä, mille käyttäjälle tietoja migratoidaan, eikä se oikeasti migratoi uudelle käytäjälle vielä mitään.

Alla suoritetun komennon tuloste:

SCANSTATE.EXE
(C) 2012 Microsoft Corporation. All rights reserved.

Log messages are being sent to 'C:\Users\USMTScanState.log'

Starting the migration process
Processing the settings store

Examining the system to discover the migration units
 S-1-12-1-1426919175-1304152533-3987183276-4051951554 (MarkusPyhäranta) (1 of 2): 100% done
 This Computer (2 of 2): 100% done

Selecting migration units

Estimating total file size for the progress log
 S-1-12-1-1426919175-1304152533-3987183276-4051951554 - 1105 files
 PF17ZVG3\Markus - 0 files
 This Computer - 1599 files

Gathering data
 S-1-12-1-1426919175-1304152533-3987183276-4051951554 (1 of 2): 100% done
 This Computer (2 of 2): 100% done
 Commit

Success.

ScanState return code: 0

Komento meni läpi. Näen molempien lokien yhteenvedosta, että ScanState-vaihe on mennyt läpi ilman virheitä:

USMTScanState.log:

[0x000000] ----------------------------------- USMT ERROR SUMMARY -----------------------------------
[0x000000] No error in migration process is recorded.

USMTScanStateProgress.log:

22 May 2020, 20:39:30 03:00, 00:00:38, errorCode, 0, numberOfIgnoredErrors, 0, message, "Successful run"

Herää kuitenkin kysymys siitä, miksi USMT skannasi ScanState-vaiheessa myös tiedostoja “This Computer” -profiilista. Tämä on normaalia ja kuuluu USMT:n toimintaperiaatteeseen. Microsoftin dokumentaatiossa How USMT Works: https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-how-it-works sanotaan mm. seuraavaa:

The system profile, the “All users” profile in a source computer running Windows XP, or the Public profile in a source computer running Windows Vista, Windows 7, and Windows 8, is always migrated and you cannot exclude these profiles from the migration.

Tuo on siis normaalia. Koska itse sisällytin ScanStateen myös kustomoidun ExcludeSystemFolders.xml -tiedoston, tiedän, ettei mitään tiedostoja tulla migratoimaan C:\Users\ -hakemiston ulkopuolelta. Pystyn tarkistamaan sen navigoimalla ScanState-komennossa määrittämääni hard-link -migraatio-varastoon komennon ajamisen jälkeen:

Migraatio-varaston sisältö käyttäjän kotihakemiston osalta:


4) Azure AD -liitos uuteen tenanttiin:

Tehtiin Azure AD -liitos uuteen tenanttiin käyttäjän uuden tenantin tunnuksilla navigoimalla Windowsissa: Asetukset > Tilit > Käytä työpaikan tai koulun resursseja > Liitä tämä laite Azure Active Directoryyn

Syötettiin pyydettäessä käyttäjän Azure AD -tunnukset. Kun liitos oli tehty, kirjauduttiin ulos paikallisen järjestelmävalvojan käyttäjätililtä. Valittiin Windowsin kirjautumisikkunassa valinta “Toinen käyttäjä” ja kirjauduttiin käyttäjän uuden tenantin Azure AD -tunnuksilla. Tällöin Windows alkoi määrittämään käyttäjäprofiilia, minkä aikana näytöllä esitettiin viestejä niitä tyypillisiä viestejä: “Tämä voi kestää useita minuutteja”, “Älä sammuta tietokonetta”, “Tietokonetta valmistellaan käyttöä varten”.

Koska kyseessä oli Azure AD -tili, organisaation käytännöt halusivat heti Windows Hello for Businessin määrittämisen. Tehtiin määritykset, minkä jälkeen päästiin Windowsin oletustyöpöydälle.

Tarkistin komentorivin komennolla, millä nimellä uusi käyttäjätili on luotu, sillä tarvitse tietoa LoadState-vaiheessa:

C:\Users\MarkusPyhära_fetjidl>whoami
azuread\markuspyhära_fetjidl

Windows 10 oli nimeni 12 ensimmäisen merkin jälkeen lisännyt alaviivan ja satunnaisen seitsemän merkin merkkijonon. Vaikka käyttäjätunnus ei suoranaisesti miellytä silmää, niin ulkoasulla ei lopulta ole mitään väliä. Käyttäjä kirjautuu Windowsiin kuitenkin Azure AD -tunnuksellaan. Jos nimi häiritsee käyttäjän kotihakemistossa, voidaan kotihakemistokansion nimi halutessa uudelleennimetä paikallisen järjestelmänvalvojatilin kautta. Sen jälkeen tulee muistaa päivittää myös käyttäjäprofiilin uusi “ProfileImagePath“-arvo rekisteriavaimeen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

5) LoadState:

Ajettiin LoadState kirjautuneena uuden tenantin käyttäjätilillä. Azure AD -liitoksen tehneelle käyttäjätilille määritetään oletuksena paikallisen järjestelmävalvojan oikeudet. Avattiin PowerShell korotetuin oikeuksin ja mentiin siihen hakemistoon, jossa loadstate.exe -ohjelma sijaitsee:

cd C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\User State Migration Tool\amd64

LoadStaten toiminnan kannalta tulee ymmärtää se, että missään vaiheessa ScanStaten prosessia ei määritellä, mille käyttäjäprofiilille tietoja ollaan siirtämässä. ScanState vain skannaa profiiliympäristön ja määrittää minkä käyttäjän tiedot migratoidaan, mutta ei mille käyttäjälle.

LoadState päättelee määrittelemieni valintojen mukaan, mitkä käyttäjäprofiilit tulisi migratoida. Oletuksena se migratoisi muuten kaikki. Samat ScanState-ohjelman kanssa käytetyt /ui ja /ue -valinnat tulee sisällyttää myös LoadStaten komentoon. LoadState ei oletuksena migratoi sellaisia käyttäjiä, joita ei löydy kohdelaitteelta jo etukäteen. Se siis pyrkii aina etsimään migratoitavaa käyttäjäprofiilia vastaavan käyttäjän myös kohdelaitteelta. Jos se ei löydä sellaista, mitään ei migratoida.

Tässä esimerkkitilanteessa olen tekemässä migraatiota Azure AD -käyttäjälle nimellä azuread\markuspyhäranta. LoadState tulee siis etsimään samannimistä käyttäjää koneelta, jolla LoadState suoritetaan. Esimerkkitilanteessani tietokone on kuitenkin sama, eli mitä tapahtuisi LoadState vaiheessa nyt? LoadState tekisi migraation käyttäjältä azuread\markuspyhäranta samalle käyttäjälle azuread\markuspyhäranta. Käytännössä olisimme siis lähtöpisteessä. Tätä ongelmaa ei tulisi vastaan, jos tehtäisiin migraatioita kahden tietokoneen välillä. Miten siis saamme LoadStaten ymmärtämään, ettei migraatio-varaston tietoja olla siirtämässä samalle lähdeprofiilille?

LoadStatesta löytyy valinta /mu, jolla voidaan uudelleennimetä käyttäjäprofiili kohdekoneella. Sillä voidaan käytännössä määrittää uusi toimialue ja käyttäjänimi migratoitavalle käyttäjälle. Uudelleennimeäminen tapahtuu periaatteella:

/mu:OldDomain\OldUsername:NewDomain\NewUserName

Koska molemmat käyttäjät ovat AzureAD -käyttäjiä, tulee sekä vanhan että uuden käyttäjän nimessä olemaan toimialueena “AzureAD”. Voimme siis tehdä nimimuutoksen seuraavasti:

/mu:azuread\markuspyhäranta:azuread\markuspyhära_fetjidl

Tuon valinnan sisällyttäminen komentoon saa LoadState-ohjelman ymmärtämään, että käyttäjäprofiilin azuread\markuspyhäranta -tiedot tullaan migratoimaan hard-link -migraatio-varastosta kohdekoneen käyttäjälle azuread\markuspyhära_fetjidl, eikä kohdekoneelta etsitä samannimistä kohdekäyttäjää kuin migraation lähteessä.

Ajettiin LoadState seuraavilla valinnoilla:

.\loadstate.exe "C:\Users\USMTStore" /hardlink /nocompress /i:migapp.xml /i:migdocs.xml /i:ExcludeSystemFolders.xml /i:MigrateBrowserAppData.xml /ui:S-1-12-1-1426919175-1304152533-3987183276-4051951554 /ue:*\* /progress:"C:\Users\USMTLoadStateProgress.log" /l:"C:\Users\USMTLoadState.log" /mu:azuread\markuspyhäranta:azuread\markuspyhära_fetjidl /v:5 /c

Mitä tuo komento siis tekee? Käydään jokainen valinta läpi:

  • loadstate.exe “C:\Users\USMTStore” = Määrittää suorittamani LoadState.exe -ohjelman ja migraatiovaraston, josta migratoitava data kopioidaan. Tässä yhteydessä ko. sijainnissa ei oikeasti sijaitse kopioitavaa dataa, vaan ainoastaan hard-linkit tiedostojen alkuperäiseen sijaintiin vanhan käyttäjän kohtihakemistossa, josta tiedostot nyt kopioidaan uudelle profiilille.
  • /hardlink = Määrittää, että data migratoidaan hard-link -varastosta.
  • /nocompress = Tämä tarvitaan aina /hardlink -valinnan kanssa. Määrittää, että migraatio-varaston dataa ei ole pakattu.
  • /i:migapp.xml = Sisällyttää komentoon migapp.xml-tiedoston, joka sisältää sääntöjä siitä, miten sovellusasetuksia tulisi migratoida.
  • /i:migdocs.xml = Sisällyttää komentoon migdocs.xml-tiedoston, joka sisältää sääntöjä siitä, miten tiedostoja ja profiiliasetuksia tulisi migratoida.
  • /i:ExcludeSystemFolders.xml = Sisällytää komentoon ExcludeSystemFolders.xml-tiedoston. Suljen sillä pois kaikki käyttöjärjestelmän tiedostohakemistot, joiden alta en halua mitään migratoitavan. Olin jo valmiiksi siirtänyt tiedoston samaan hakemistoon.
  • /i:MigrateBrowserAppData.xml = Sisällytää komentoon MigrateBrowserAppData.xml-tiedoston. Sisällytän sillä migraatioon kaikki tiedostot ja alikansiot Google Chrome ja Mozilla Firefox -selainten profiilihakemistoista, joiden alta haluan migratoitavan mm. kirjanmerkit, tallennetut salasanat ja niin edelleen. Olin jo valmiiksi siirtänyt tiedoston samaan hakemistoon.
  • /ui:S-1-12-1-1426919175-1304152533-3987183276-4051951554 = Määrittää migratoinnin piiriin kuuluvat käyttäjäprofiiit, eli tässä tapauksessa vain käyttäjäprofiilin “S-1-12-1-1426919175-1304152533-3987183276-4051951554”
  • /ue:*\* = Määrittää migratoinnin piiriin kuulumattomat käyttäjäprofiilit, eli tässä tapauksessa aivan kaikki käyttäjäprofiilit huolimatta toimialueesta ja sijainnista. Valinta /ui voittaa aina, jos sen ja /ue -valinnan kanssa tulee ristiriita. Esimerkiksi profiili “S-1-12-1-1426919175-1304152533-3987183276-4051951554” on nyt sekä sisällytetty migraatioon että jätetty sen ulkopuolelle. /ui -valinta kuitenkin ottaa prioriteetin, joten se sisällytetään ja kaikki muut jätetään pois.
  • /progress:”C:\Users\USMTLoadStateProgress.log” = Määrittää valinnaisen progress-lokin sijainnin hakemistoon C:\Users\USMTLoadStateProgress.log. Sisältää mm. virheilmoitukset.
  • /l:”C:\Users\USMTLoadState.log” = Määrittää LoadState-lokin sijainnin hakemistoon C:\Users\USMTLoadState.log.
  • /mu:azuread\markuspyhäranta:azuread\markuspyhära_fetjidl = Esitetään muutos käyttäjänimessä. Eli migraation kohdetietokoneelta tullaan etsimään käyttäjää “azuread\markuspyhära_fetjidl” migraation kohteeksi. Migraation lähteenä toimii käyttäjän “azuread\markuspyhäranta” käyttäprofiili, joka määritettiin sen SID-tunnuksella valinnassa /ui.
  • /v:5 = Määrittää lokitettavien tietojen tason, eli mitä halutaan lokitettavan LoadState-komennon toimista.
  • /c = Määrittää, että LoadState-komento tulee ajaa loppuun, vaikka virheilmoituksia tulisikin. Virheiden merkityksellisyys on jälkeenpäin arvioitavissa lokitiedoista.

Komennolla siis käytännössä määritettiin, mitä migratoidaan, mistä sijainnista, miten ja millä nimellä käyttäjäprofiilin tulisi migraation jälkeen sijaita kohteessa.

Alla suoritetun komennon tuloste:

LOADSTATE.EXE Version 10.0.18362
(C) 2012 Microsoft Corporation. All rights reserved.

Log messages are being sent to 'C:\Users\USMTLoadStateFINAL.log'

Starting the migration process
Processing the settings store

Selecting migration units

Examining the system to discover the migration units
 AzureAD\MarkusPyhära_fetjidl (1 of 2): 100% done
 This Computer (2 of 2): 100% done

Estimating total file size for the progress log
 AzureAD\MarkusPyhära_fetjidl - 0 files
 S-1-12-1-1426919175-1304152533-3987183276-4051951554 - 1105 files
 PF17ZVG3\Markus - 0 files
 This Computer - 34 files

Applying data
 S-1-12-1-1426919175-1304152533-3987183276-4051951554 (1 of 2): 100% done
 This Computer (2 of 2): 100% done

Success.

LoadState return code: 0

Komento meni läpi. Näen myös lokeista, että komento suoritui ilman virheilmoituksia.

USMTLoadState.log:

[0x000000] ----------------------------------- USMT ERROR SUMMARY -----------------------------------
[0x000000] No error in migration process is recorded.

USMTLoadStateProgress.log:

22 May 2020, 20:59:52 03:00, 00:02:46, errorCode, 0, numberOfIgnoredErrors, 0, message, "Successful run"

6-8) Viimeistelevät toimenpiteet:

Kun LoadState oli valmis, kirjauduin kerran ulos ja takaisin käyttäjän uuden tenantin Azure AD -tunnuksella. Tietyt asetukset, kuten fontit, taustakuva, tehtäväpalkin pikakuvakkeet ja näytönsäästäjän asetukset eivät muuten tule voimaan.

Uudelleenkirjautumisen jälkeen muutokset olivat suoraan havaittavissa:

Varmistin huolellisesti ScanStaten ja LoadStaten progress-lokeista, ettei mitään kriittisiä virheitä tapahtunut toimenpiteiden aikana, eikä mitään oleellista ollut jäänyt migratoimatta. ScanStaten-lokit arvioin jo vaiheessa 3) ja LoadStaten vaiheessa 5). Tiedän, ettei migraation aika esiintynyt mitään virheitä, jotka voisivat aiheuttaa tiedonmenetystä käyttäjän datan osalta.

Tarkistin käyttäjän kotihakemiston, enkä havainnut minkään puuttuvan. Navigoin resurssienhallinnasta manuaalisesti hard-link-varaston sijaintiin C:\Users\USMTStore ja poistin sen lopullisesti. Poistotoimenpide ei poista dataa alkuperäiseltä käyttäjäprofiililta, vaan ainoastaan tiedostoihin luodut hard-linkit.

Huomasin, että ainakaan Mozilla Firefox ei ymmärtänyt käyttää AppData-kansiosta löytyvää migratoitua profiilikansiota uudelle Firefoxin oletusprofiilille. Siksi jouduin uudelleennimeämään migratoidun profiilikansion vastaamaan oletusprofiilikansion kansionimeä, jonka näin syöttämällä osoiteriville about:profiles. Tässä ohjeet: https://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles

Jos vanhalle käyttäjälle ei ole tarvetta, voidaan koko profiili poistaa esimerkiksi navigoimalla: Ohjauspaneeli > Järjestelmä ja suojaus > Järjestelmä > Järjestelmän lisäasetukset > Käyttäjäprofiilit – Asetukset… > valitaan vanha käyttäjäprofiili > Poista.


Aiheeseen liittyen:


TÄTÄ DOKUMENTTIA SAA KOPIOIDA JA MUOKATA GNU GENERAL PUBLIC LICENSE (VERSIO 3 TAI UUDEMPI) MUKAISESTI. HTTP://WWW.GNU.ORG/LICENSES/GPL.HTML
MARKUS PYHÄRANTA
Markus Pyhäranta

RELATED ARTICLES
LEAVE A COMMENT