У цьому розділі розглядається User State Migration Tool (USMT) — набір інструментів для перенесення користувацького середовища між Windows-системами.
Пояснюється поняття User State, роль ScanState і LoadState, Migration Store та XML-правил міграції, а також використання USMT у сценаріях PC Refresh і PC Replacement.
Microsoft прямо описує USMT як інструмент для перенесення облікових записів, файлів користувача, налаштувань Windows і налаштувань програм; він призначений, зокрема, для PC Refresh та PC Replacement.
👤 USMT
│
├── 1. Що таке User State
│
├── 2. ScanState
│
├── 3. LoadState
│
├── 4. Migration XML
│ ├── MigUser.xml
│ ├── MigDocs.xml
│ ├── MigApp.xml
│ └── Custom XML
│
├── 5. Migration Store
│
├── 6. Перенесення користувачів
│
├── 7. Файли користувача
│
├── 8. Налаштування Windows
│
├── 9. Налаштування програм
│
├── 10. PC Refresh
│
├── 11. PC Replacement
│
└── 12. USMT + WinPE + Deployment
User State — це не сама Windows і не Windows Image.
Це те, що належить конкретному користувачеві та його робочому середовищу:
👤 User State
│
├── User Accounts
│
├── Personal Files
│ ├── Documents
│ ├── Desktop
│ ├── Pictures
│ └── other user data
│
├── Windows Settings
│
├── Application Settings
│
└── інші визначені правилами міграції дані
USMT дозволяє визначити, що саме потрібно забрати зі старої системи і що потрібно відновити на новій.
Тобто:
Windows Image
=
сама операційна система / базове середовище
User State
=
дані + налаштування конкретного користувача
Це принципово різні речі.
ScanState.exe — інструмент, який працює на source computer.
Його задача:
Source PC
↓
ScanState
↓
аналіз User State
↓
Migration Store
ScanState збирає файли та налаштування із вихідної системи та створює migration store.
Наприклад:
Старий ПК
│
├── User Account
├── Documents
├── Desktop
├── Windows Settings
└── Application Settings
│
▼
ScanState
│
▼
Migration Store
Важливий момент для BAT:
ScanState не є просто "копіювальником файлів".
Він працює разом із migration rules, XML-файлами та параметрами користувачів, тому можна контролювати, що саме потрапить до міграції.
LoadState.exe виконує протилежну операцію.
Migration Store
↓
LoadState
↓
Destination PC
↓
відновлений User State
Тобто:
SCANSTATE
старий Windows
↓
Migration Store
↓
LOADSTATE
↓
новий Windows
LoadState відновлює збережений migration store на destination computer. Microsoft рекомендує запускати його з адміністративними правами.
Ось тут USMT стає особливо цікавим.
USMT використовує XML-файли як набір правил міграції. Microsoft постачає:
XML
│
├── MigUser.xml
├── MigDocs.xml
├── MigApp.xml
└── Custom XML
MigUser.xml — правила для користувацьких файлів, папок і типів файлів.
MigDocs.xml — правила для пошуку та міграції документів і користувацьких даних.
MigApp.xml — правила для налаштувань програм.
Custom XML — власні правила організації.
Це означає, що BAT Systems Group може показати USMT не як:
«запустив ScanState → запустив LoadState»
а як керовану систему правил:
Source
│
▼
Migration XML
│
├── що забрати?
├── що пропустити?
├── які налаштування?
└── куди відновити?
│
▼
ScanState
Це особливо цікаво для практики BAT.
Якщо стандартних правил недостатньо, можна створити власний XML-файл для конкретної організації або сценарію.
Наприклад:
Custom.xml
│
├── Application A
├── Application B
├── специфічні папки
├── специфічні налаштування
└── власні правила міграції
Microsoft прямо передбачає створення custom XML для унікальних потреб організації, наприклад для line-of-business applications.
USMT може переносити user accounts та user settings.
Причому вибір користувачів не задається migration XML — Microsoft зазначає, що користувачів включають або виключають через параметри ScanState/LoadState.
Схема:
Old PC
│
├── User A
├── User B
└── User C
│
▼
USMT rules
│
▼
Migration Store
│
▼
New PC
│
├── User A
└── User B
Тобто можна побудувати міграцію не обов'язково для всіх користувачів.
USMT може переносити персональні файли та папки, визначені правилами міграції.
Наприклад:
👤 User
│
├── Documents
├── Desktop
├── Pictures
├── user folders
└── інші визначені дані
Але тут важливо не робити помилковий висновок:
USMT ≠ повний backup диска.
Він переносить саме ті дані, які визначені migration rules.
USMT може переносити певні операційні налаштування, пов'язані з User State.
Наприклад, після міграції частина користувацького середовища може знову з'явитися на новій системі.
Але це не означає:
USMT
↓
повна копія Windows Registry
Ні.
USMT працює через визначені Microsoft правила міграції, тому його правильніше сприймати як керований перенос user state, а не як клонування системи.
Це одна з найцікавіших можливостей USMT.
MigApp.xml містить правила для міграції application settings.
Тому логіка може бути:
Старий Windows
│
├── User files
├── Windows settings
└── Application settings
│
▼
ScanState
│
▼
Migration Store
│
▼
LoadState
│
▼
Новий Windows
│
├── User files
├── Windows settings
└── Application settings
Але тут є важливе практичне правило:
спочатку треба мати відповідну програму на destination system, якщо її налаштування потрібно використовувати.
Microsoft окремо рекомендує планувати, які application settings переносити, і не відновлювати налаштування програм, яких на новій системі немає.
PC Refresh — це ситуація, коли користувач залишається на тому самому фізичному ПК, але Windows перевстановлюється або оновлюється.
SAME PC
│
┌─────┴─────┐
│ │
Old Windows New Windows
│ ▲
│ │
└→ USMT ────┘
Типовий сценарій:
Old Windows
↓
ScanState
↓
Migration Store
↓
Windows deployment
↓
New Windows
↓
LoadState
↓
User State restored
Microsoft описує також варіант із hard-link migration store, коли дані залишаються на тому самому ПК і не обов'язково передаються через мережу.
Тут уже змінюється фізичний комп'ютер.
OLD PC
│
│ ScanState
▼
Migration Store
│
│
▼
NEW PC
│
│ LoadState
▼
User State
Це дуже хороший deployment-сценарій для BAT:
Старий ПК
↓
збір User State
↓
Migration Store
↓
новий ПК
↓
Windows Image
↓
Deployment
↓
LoadState
↓
користувач отримує своє середовище
Microsoft прямо відносить PC replacement до основних сценаріїв USMT.
А ось тут USMT дуже красиво входить у нашу попередню архітектуру BAT.
Microsoft підтримує offline migration, зокрема запуск ScanState із WinPE. Також USMT може працювати із попередньою Windows через Windows.old.
Отримуємо повний ланцюг:
🚀 BAT Deployment
│
┌───────────┼───────────┐
▼ ▼ ▼
Windows Image WSIM USMT
│ │ │
│ │ User State
│ │ │
│ │ ┌─────┴─────┐
│ │ ▼ ▼
│ │ ScanState Migration XML
│ │ │
│ │ ▼
│ │ Migration Store
│ │ │
└───────────┴─────┼───────┐
▼ │
New Windows │
│ │
▼ │
LoadState ◄─┘
│
▼
Configured User
Інструмент
Головне питання
DISM
Що робити з Windows Image?
WSIM
Як Windows Setup має встановити й налаштувати Windows?
WCD
Як налаштувати вже встановлену Windows через provisioning?
USMT
Як перенести User State користувача?
WinPE
Де виконати ці операції, коли Windows ще не запущена?
Це дуже сильна концептуальна зв'язка для BAT Deployment.
USMT не є універсальним «переносом будь-якої Windows на будь-яку Windows».
Наприклад, Microsoft вказує обмеження щодо підтримуваних сценаріїв, зокрема USMT не підтримує Windows Server, не підтримує Microsoft Entra joined devices як source/destination і має обмеження щодо Microsoft Store apps.
Тому на BAT сайті я б не називав USMT просто "перенесенням Windows".
Правильніше:
кероване перенесення користувацького стану між підтримуваними Windows-інсталяціями.
5. 👤 User State Migration Tool — USMT
│
├── 1. 👤 Що таке User State
│
├── 2. 📦 ScanState
│
├── 3. 🔄 LoadState
│
├── 4. 📄 Migration XML
│ ├── MigUser.xml
│ ├── MigDocs.xml
│ ├── MigApp.xml
│ └── Custom XML
│
├── 5. 📦 Migration Store
│
├── 6. 👥 Перенесення користувачів
│
├── 7. 📂 Файли користувача
│
├── 8. ⚙️ Налаштування Windows
│
├── 9. 🧩 Налаштування програм
│
├── 10. 🔄 PC Refresh
│
├── 11. 💻 PC Replacement
│
└── 12. 🖥️ USMT + WinPE + Deployment