У цьому розділі розглядаються Application Virtualization (App-V) та User Experience Virtualization (UE-V) — технології Microsoft, які відігравали роль у корпоративному Deployment та керуванні користувацьким середовищем.

App-V розглядається з точки зору віртуалізації та централізованої доставки Win32-застосунків, а UE-V — з точки зору перенесення та синхронізації користувацького досвіду.

Окремо зазначається їхній legacy-статус, щоб показати не лише сучасні інструменти Deployment, а й еволюцію підходів Microsoft до керування застосунками та користувацьким середовищем.

📦 App-V / UE-V 

App-V 5.1 мав завершення підтримки 14 квітня 2026 року, а UE-V 2.1 — також 14 квітня 2026 року. При цьому App-V client у Windows перейшов у fixed extended support, але сам напрямок більше не розвивається; серверні компоненти App-V завершили підтримку у квітні 2026. 

📦 App-V / UE-V

│

├── 1. 📦 App-V

│      ├── Application Virtualization

│      ├── Win32 applications

│      ├── Віртуалізований запуск застосунків

│      ├── Централізована доставка

│      └── App-V Client

│

├── 2. 👤 UE-V

│      ├── User Experience Virtualization

│      ├── Налаштування користувача

│      ├── Налаштування програм

│      └── Синхронізація User Experience

│

└── 3. ⚠️ Legacy Deployment

       ├── Історична роль у Microsoft Deployment

       ├── Старі корпоративні середовища

       └── Сучасні альтернативи

1. 📦 App-V — Application Virtualization

Microsoft Application Virtualization (App-V) був призначений для доставки Win32-застосунків користувачам без традиційного встановлення застосунку безпосередньо в Windows. Microsoft описує App-V як механізм, що перетворює застосунки на централізовано керовані сервіси.

Тобто класична модель:

Звичайний Deployment

Windows Image

     ↓

Windows

     ↓

Install Application

     ↓

Application у системі

А App-V будував іншу модель:

Windows

   ↓

App-V Client

   ↓

App-V Application

   ↓

Віртуалізоване середовище застосунку

Ідея полягала в тому, щоб відокремити застосунок від базової Windows-системи.

Навіщо це було потрібно

Наприклад, у корпоративному середовищі могли бути десятки або сотні комп'ютерів.

Замість того щоб:

PC 01 → install App

PC 02 → install App

PC 03 → install App

PC 04 → install App

...

можна було централізовано керувати доставкою застосунку через App-V.

Це особливо цікаво з точки зору Deployment, тому що з'являється поділ:

Windows Base

     +

Applications

а не одна величезна кастомізована система, де все вже «запечено» всередину install.wim.

App-V і Windows Image

Це важливе для нашої карти Deployment:

             Windows Image

                   │

                   ▼

             Base Windows

                   │

                   ▼

              App-V Client

                   │

                   ▼

          Virtualized Application

Тобто App-V міг бути наступним шаром після розгортання базової Windows.

2. 👤 UE-V — User Experience Virtualization

UE-V (User Experience Virtualization) вирішував уже іншу задачу.

Якщо App-V відповідав переважно на питання:

«Як доставити застосунок?»

то UE-V був про:

«Як зберегти/перенести користувацьке середовище та налаштування?»

Концептуально:

Користувач

   │

   ├── Windows Settings

   ├── Application Settings

   └── User Experience

          │

          ▼

         UE-V

          │

          ▼

     Інший Windows PC

Тобто користувач міг отримувати більш знайоме середовище при роботі на іншому комп'ютері.

Важлива відмінність від USMT

Не змішуємо UE-V з попереднім розділом USMT.

USMT:

PC A

 │

 ├── ScanState

 │

 ▼

Migration Store

 │

 └── LoadState

       ↓

      PC B

Це інструмент міграції User State у рамках конкретного deployment/refresh/replacement-сценарію.

UE-V був орієнтований на збереження/синхронізацію користувацького досвіду між пристроями.

Тому:

USMT → Migration

UE-V  → User Experience Synchronization

Це різні задачі.

3. ⚠️ Чому App-V / UE-V тепер Legacy

Ось тут на BAT Systems Group треба поставити чітку позначку.

Microsoft вказує, що:

• Microsoft Application Virtualization 5.1 — завершення extended support: 14 квітня 2026 року;

• UE-V 2.1 — завершення підтримки: 14 квітня 2026 року.

Тобто станом на 2026 рік це вже не технології, навколо яких варто будувати новий Deployment.

Для App-V Microsoft у своїй документації прямо вказує на сучасний напрямок MSIX app attach в Azure Virtual Desktop як альтернативу.

Тому BAT може показати цей розділ як історичний шар розвитку Deployment, а не як рекомендацію:

App-V / UE-V

       │

       ▼

 Legacy Microsoft Deployment

       │

       ├── корисно для розуміння старих систем

       ├── корисно для legacy-міграцій

       └── не основа нового Deployment

4. Як це вписується в BAT Deployment

Якщо дивитися на всю нашу архітектуру, виходить дуже логічна картина:

🚀 BAT Deployment

│

├── 🧰 Deployment Tools

│      └── Створення / обслуговування Windows Image

│

├── 🖥️ Windows PE

│      └── Середовище виконання Deployment

│

├── 🧩 Windows Configuration Designer

│      └── Provisioning / .ppkg

│

├── ⚙️ WSIM

│      └── Windows Setup / unattend.xml

│

├── 👤 USMT

│      └── User State Migration

│

├── 📊 Windows Performance Toolkit

│      └── Performance Analysis

│

├── 🧪 Windows Assessment Toolkit

│      └── Assessment

│

├── 🛠️ Application Compatibility

│      └── Compatibility

│

└── 📦 App-V / UE-V

       │

       ├── App-V

       │    └── Application Virtualization

       │

       ├── UE-V

       │    └── User Experience Virtualization

       │

       └── ⚠️ Legacy

Важливий актуальний момент: App-V 5.1 і UE-V 2.1 завершили підтримку 14 квітня 2026 року. Тому на сайті їх варто подати як legacy-технології Microsoft, які важливі для розуміння старих Deployment-середовищ, але не як рекомендовану основу для нових систем.