VixWin Platinum 3.6.3 через GPO: подготовка профиля до первого запуска

Практический кейс Active Directory: перенос пользовательских настроек VixWin, HKCU, roaming profiles, общая база на NAS, PowerShell и сценарии входа GPO.

Проверено на: VixWin Platinum 3.6.3 · Windows 11 · Active Directory · PowerShell 5.1 · GPO User Logon Scripts · Roaming Profiles

Задача и результат

При переходе с локальных учётных записей Windows на доменные выяснилось, что VixWin Platinum 3.6.3 сохраняет существенную часть настроек в HKCU. Новый пользователь получал мастер первого запуска с выбором языка, режима работы и предложением создать новую базу. Хотя существующая база изображений была доступна на сетевом диске, список пациентов оставался пустым: в профиле был указан локальный диск C:.

В октябре 2026 года внедрили схему пользовательская GPO → CMD logon script → PowerShell-обёртка → HKCU. На двух Windows 11 AD-станциях проверили подготовку профиля до первого открытия VixWin. Приложение запускалось без мастера и использовало уже существующую сетевую базу. После пилота разрешение применения GPO перевели на группу из десяти доменных пользователей. Отдельную проверку открытия и редактирования каждого изображения этот сценарий не заменяет.

Обезличивание: ad.example.com, CORP, PC-01, PC-02, nas01, user01 и названия групп ниже — условные примеры. Реальные имена клиники, домена, NAS, адреса, пользователи, .reg-файлы и пациентские изображения не публикуются. Публичные примеры скриптов — адаптация испытанного решения, а не точная production-конфигурация.

1. Где находятся настройки

Основная ветка — HKCU\Software\Gendex\VixWin32, в том числе разделы Setup, Preferences, Database, Customize, Toolbar, Toolbox и UserInterface. Общий файл C:\vixwin\VIXWIN.INI в обследованной системе содержал лишь Database=1; копирования INI было недостаточно.

Вместо экспорта всей ветки Gendex использовали только четыре UI-раздела: Customize, Toolbar, Toolbox и UserInterface. Ветки DICOM, CCDSensor, параметры оборудования и лицензирования не копировали: они могут зависеть от конкретного рабочего места.

2. Причина сброса пути к базе

На первом этапе UI-разделы импортировали новому доменному пользователю, а путь к существующей базе исправляли вручную. Однако при первом запуске VixWin выполнял собственную инициализацию и возвращал Dbdrive / DefaultImageDrive к C. Повторное применение конфигурации восстанавливало Z: и пациентский список.

DatabaseReadOnly=1 — наблюдённое значение конкретной установки, а не универсальная рекомендация. Для другой инфраструктуры необходимы проверка поведения программы, прав SMB и политики изменения изображений.

3. Предварительная инициализация HKCU

Следующий эксперимент устранил повторный мастер: до запуска программы в чистом пользовательском HKCU создавали восемь значений с правильными типами.

Затем импортировали четыре UI-раздела. Под новым пользователем VixWin открывался сразу, без выбора языка, режима и предложения создать новую базу. Если профиль уже существовал, скрипт проверял Setup, язык и режимы базы и останавливался на неожиданных значениях, не пытаясь «починить» неизвестную конфигурацию.

4. Схема развёртывания

Active Directory (OU пользователей)
  GPO-Example-User-VixWin, пилотная/основная AD-группа
     |
     v
  CMD logon script (от имени пользователя)
     |
     v
  PowerShell launcher, ожидание сетевого диска Z: до 60 секунд
     |
     v
  Allowlist: компьютер + пользователь
  Правильный NAS и существующий каталог Z:\VXDATA
  SHA256 четырёх приватных .reg эталонов
     |
     v
  Прединициализация HKCU при новом профиле
  Резервная копия HKCU при существующем профиле
  Импорт UI + проверка пути к базе
  Журнал + маркер версии + повторный SKIP

Исполнять от SYSTEM нельзя: пользовательский HKCU и подключённые сетевые диски имеют другой контекст. Обёртка сама диск не подключает, а ожидает его появления после отдельной GPO Drive Maps. Если NAS недоступен, запись в HKCU не выполняется; повторная попытка предусмотрена при следующем входе.

Скрипты не устанавливают VixWin, не создают базу пациентов, не обрабатывают снимки, не меняют DICOM и ACL NAS.

5. Две GPO, две разные области

Пользовательская GPO привязывается к OU пользователей. Для корректной выборки оставляют Authenticated Users = GpoRead, пилотной группе сначала выдают GpoApply, а после проверки переносят его на производственную группу. Дополнительные allowlist-проверки внутри PowerShell ограничивают компьютеры, где вообще допускаются изменения.

Сценарий размещается в User Configuration → Policies → Windows Settings → Scripts (Logon).

Отдельная компьютерная GPO привязывается к OU рабочих станций и фильтруется по группе двух разрешённых ПК. Для неё применили параметр:

HKLM\SOFTWARE\Policies\Microsoft\Windows\System
EnableLogonScriptDelay (DWORD) = 0

Это убирает стандартную задержку входных сценариев, но не делает выполнение синхронным. В пилоте запуск сценария фиксировался примерно одновременно с появлением Explorer (разница 0–1 секунда); завершение занимало ещё 3–4 секунды. Поэтому прежде чем открывать VixWin на первом входе, нужно дождаться подготовки профиля.

6. Логи, повторный запуск и восстановление

Скрипт проверяет наличие приложения, правильное сопоставление Z:, существование Z:\VXDATA и SHA256 UI-эталонов, затем сохраняет реестр существующего пользователя в индивидуальный .reg. При новом HKCU сохранять нечего. Маркер версии в отдельной HKCU-ветке позволяет SKIP при повторном входе.

Типичный журнал:

Fresh VixWin profile detected
Initialized fresh user profile with 8 verified registry values
Imported: Customize.reg
Imported: Toolbar.reg
Imported: Toolbox.reg
Imported: UserInterface.reg
SUCCESS: unified VixWin preinit/UI/database deployment
SKIP: version already applied; required registry state healthy

Ограничение: проверка UI в SKIP контролирует наличие разделов, а не равенство каждого элемента интерфейса. Это позволяет сохранять персональные изменения раскладки.

Проверка результата:

whoami
gpresult /scope user /r
Test-Path 'Z:\VXDATA'
Get-ItemProperty 'HKCU:\Software\Gendex\VixWin32\Database' |
  Select-Object Dbdrive,Dbmode,DefaultImageDrive,DatabaseReadOnly,LastPath

При проблеме сначала отключите применение GPO, штатно завершите сеанс, восстановите персональную резервную копию HKCU и проверьте NAS. Создавать новую локальную базу вместо существующей — неверный способ исправить пустой пациентский список.

При использовании перемещаемых профилей нужно корректно выходить из первой сессии перед входом на другой компьютер, иначе HKCU может рассинхронизироваться.

7. Безопасность публикации

В публичный GitHub нельзя включать реальные UI .reg без аудита, названия клиники, DICOM AETitle, имена NAS и рабочих станций, IP и фотографии пациентов. В подготовленном демонстрационном коде домен, пользователи, сервер и хеши заменены. Примерные SHA256 намеренно недействительны: скрипт не должен начать менять профиль без внутренней конфигурации.

Контроль SHA256 не защищает от атакующего, способного заменить и шаблон, и ожидаемый хеш: ограничивайте право записи в NETLOGON, а ExecutionPolicy Bypass не воспринимайте как защиту.

Вывод

Для legacy-приложений миграция доменных пользователей может потребовать инициализации HKCU до первого запуска, а не обычного импорта .reg или копирования INI. Важны права и доступность сетевой базы, контекст выполнения, GPO security filtering, контроль репликации SYSVOL, время сценариев входа и безопасный rollback.

Смежные кейсы: 7-Zip через GPO и диагностика Veyon и Active Directory.

Примеры скриптов на GitHub

Обезличенный демонстрационный комплект опубликован в greksw/vixwin-gpo-deployment: PowerShell-инициализация HKCU, обёртка logon script, CMD-ярлык и описание настройки GPO. Реальные клинические .reg-экспорты не публикуются. Хеши в примерах заведомо недействительны; это не готовый production-деплой.