АйТи Фреш
Главная / Статьи / Windows и рабочие места
Windows и рабочие места

Откатил оба контроллера Windows Server 2025 к снимкам: репликация AD идёт, а SYSVOL встал намертво. Почему VM-Generation ID не спас и как чинить

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~22 мин чтения
Откатил оба контроллера Windows Server 2025 к снимкам: репликация AD идёт, а SYSVOL встал намертво. Почему VM-Generation ID не спас и как чинить
Иллюстрация к статье «Откатил оба контроллера Windows Server 2025 к снимкам: репликация AD идёт, а SYSVOL встал намертво. Почему VM-Generation ID не спас и как чинить».

Вечером откатили обе виртуалки контроллеров домена к снимкам — после неудачного обновления, после шифровальщика, после «мы тут поправили схему». Утром домен как будто живой: пользователи входят, LDAP отвечает, repadmin рисует нули в колонке ошибок. И при этом ни одна групповая политика не применяется, логон-скрипты не отрабатывают, сетевые диски не подключаются. Ниже — почему так происходит, чем именно VM-Generation ID вам помог (а чем нет), и полная процедура возврата SYSVOL в строй: команды, атрибуты, события в журналах и порядок действий, при котором вы не разнесёте домен окончательно.

Как это выглядит в понедельник утром

Симптом всегда один и тот же, и он обманчиво спокойный. Домен отвечает. Аутентификация работает, Kerberos выдаёт билеты, пользователи заходят на терминалку. Админ смотрит repadmin /replsum, видит чистую таблицу и делает вывод: восстановились нормально. А в это время у половины офиса не подключился диск P:, не запустился ярлык 1С из политики, не подтянулись принтеры этикеток со штрихкодами, и техподдержка захлёбывается в заявках «у меня всё пропало».

Дело в том, что репликация Active Directory и репликация SYSVOL — это два разных механизма. AD реплицируется службой каталогов по DRS-RPC. SYSVOL — папка с групповыми политиками и скриптами — реплицируется отдельной службой DFS Replication (или древней NTFRS, если домен ни разу не мигрировали). Они восстанавливаются независимо, и после отката из снимка первая поднимается сама, а вторая — нет.

Поэтому первое, что я проверяю после любого отката контроллера, — не репликацию каталога, а именно готовность SYSVOL. Четыре проверки, полминуты времени:

# 1. Есть ли шары групповой политики
net share | findstr /i "SYSVOL NETLOGON"

# 2. Считает ли контроллер себя готовым
dcdiag /test:sysvolcheck /test:advertising

# 3. Флаг готовности SYSVOL (нужна 1)
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters SysvolReady

# 4. Что говорит сама служба репликации
Get-WinEvent -LogName "DFS Replication" -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
dfsrdiag ReplicationState /all

Если net share не показывает NETLOGON и SYSVOL, а SysvolReady равен нулю — контроллер не рекламирует себя как DC для целей групповой политики. Клиенты продолжают ходить к нему за LDAP и Kerberos, но за политиками идти некуда. Отсюда и «домен работает, а политик нет».

Зелёный repadmin после отката контроллеров не значит ничего. Он проверяет каталог, а простой офиса вызван остановленной репликацией SYSVOL. Проверяйте эти две вещи по отдельности — всегда.

Что VM-Generation ID делает на самом деле

Механизм красивый и работает без единой настройки. Гипервизор выдаёт виртуальной машине идентификатор — VM-Generation ID. Контроллер домена сохраняет это значение в своей базе NTDS.dit — в атрибуте msDS-GenerationId собственного компьютерного объекта; атрибут заполняется при первой перезагрузке после повышения (до этого в журнале будет событие 2173) и между контроллерами не реплицируется. При каждой загрузке AD DS сравнивает то, что лежит в NTDS.dit, с тем, что отдаёт драйвер счётчика поколений. Совпало — обычная загрузка. Не совпало — значит машину развернули из копии или откатили к снимку, и включаются «предохранители виртуализации».

Предохранителей ровно два, и оба — про предотвращение расхождения каталога. Контроллер сбрасывает свой Invocation ID (генерирует новый GUID для контекста репликации) и выбрасывает локальный пул RID. Первое не даёт повторно выдать те же самые USN другим объектам и породить классический USN rollback с зависшими объектами; второе не даёт создать два разных объекта с одинаковым SID. Формулировка Microsoft буквально такая: «the domain controller resets the Invocation ID and discards the RID pool, thereby preventing USN reuse or the potential creation of duplicate security-principals».

Дальше контроллер начинает неавторитетную входящую репликацию каталога от партнёра — забирает всё, что у него отстало, и заодно получает обратно свои же изменения, которые он потерял при откате, но успел отдать соседу до снимка. И вот тут ключевое: параллельно он помечает свою реплику SYSVOL как неавторитетную. Для DFSR это означает удаление файлов базы DFSR (по умолчанию C:\System Volume Information\DFSR\<GUID базы>; содержимое самой папки SYSVOL при этом не удаляется и используется как предзаполнение) и запуск синхронизации «от партнёра». Для FRS — установку BURFLAGS в D2. То есть контроллер сознательно объявляет: моя копия политик недостоверна, дайте мне правильную.

Проверить, что предохранители сработали, можно по журналам. В Directory Services вы увидите событие 2170 «A Generation ID change has been detected» со старым и новым значениями, событие 1109 о смене invocationID, а в System — 16654 «A pool of account-identifiers (RIDs) has been invalidated». Если вместо 2170 у вас 2171 «No Generation ID change has been detected», значит гипервизор идентификатор не поменял, и это отдельная беда, о ней ниже.

Сожжённый пул RID — не проблема. Каждый откат выбрасывает пятьсот идентификаторов из миллиарда доступных домену. Пугаться тут нечего; пугаться надо совсем другого.
Откатил оба контроллера Windows Server 2025 к снимкам: репликация AD идёт, а SYSVOL встал намертво. Почему VM-Generation ID не спас и как чинить — схема
Схема к статье. Открыть схему в полном размере

Почему одновременный откат всех контроллеров ломает SYSVOL

Логика предохранителей строится на одном допущении: рядом есть живой партнёр с правильными данными. Microsoft это прямым текстом фиксирует в требованиях к virtualization safeguards: «There is a valid partner domain controller that a restored domain controller can replicate changes from non-authoritatively». И отдельно оговаривает, что восстановленный контроллер обязан достучаться именно до записываемого DC — RODC источником дельты быть не может, он физически не умеет отдавать изменения в эту сторону.

Теперь представьте, что вы откатили не один контроллер, а все. У домена два DC, вы вернули из снимков оба. Каждый из них увидел смену VM-Generation ID, каждый честно объявил свою реплику SYSVOL неавторитетной и каждый пошёл искать партнёра, у которого копия достоверна. А достоверной копии больше нет ни у кого. Оба стоят в позе ожидания и ждут друг друга. Классический дедлок.

Microsoft описывает этот сценарий буквально: «If all snapshots restore at once, Active Directory replication works normally but SYSVOL replication halts… they all will then try to synchronize group policies and scripts from an authoritative partner; at that point, though, all partners are also non-authoritative». Обратите внимание на первую половину фразы — репликация каталога работает нормально. Именно поэтому диагностика по repadmin успокаивает и уводит в сторону.

Сам по себе домен из этого состояния не выйдет. Никогда. Ждать бесполезно, перезагрузка не поможет, рестарт службы DFSR не поможет. Нужно вручную назначить один контроллер авторитетным источником SYSVOL — и тогда остальные получат от него данные.

Типовая ловушка — «откатить оба на всякий случай». Если проблема действительно на обоих DC, откатывайте по одному: сначала один, дождитесь в его журнале DFS Replication событие 4604 (SYSVOL синхронизирован с живым партнёром), только потом второй. Иначе вы своими руками строите описанный выше дедлок.
Памятка: Почему одновременный откат всех контроллеров ломает SYSVOL — схема
Памятка: Почему одновременный откат всех контроллеров ломает SYSVOL. Открыть схему в полном размере

Разбор: медлаборатория «Анализ-Лаб», 26 рабочих мест, два DC на Windows Server 2025

Медицинская лаборатория «Анализ-Лаб»: основной корпус с аналитическим залом и два пункта забора, 26 рабочих мест, домен из двух контроллеров — DC01 (держит PDC Emulator, он же DNS) и DC02. Обе машины — виртуалки Windows Server 2025 на двух хостах Hyper-V в серверной, SYSVOL около 310 МБ, 19 объектов групповой политики: логон-скрипты подключения дисков, ярлыки лабораторной информационной системы, принтеры этикеток со штрихкодами для пробирок. Подрядчик по ЛИС в пятницу вечером ставил обновление и попутно попросил «на всякий случай сделать снимки контроллеров». Снимки сделали. В субботу начались проблемы с профилями, и штатный админ откатил к снимкам обе виртуалки. Логика понятная: раз проблема на обоих, значит и откатывать оба.

В понедельник в 7:40, когда открылся первый пункт забора, посыпались звонки. Картина ровно та, что описана выше: вход в домен работает, repadmin /replsum чистый, dcdiag /test:replications проходит, а сетевые диски не подключены ни у кого, ярлык ЛИС на рабочих столах пропал, этикетки не печатаются. На обоих контроллерах отсутствуют шары NETLOGON и SYSVOL, SysvolReady = 0. В Directory Services на обеих машинах — событие 2170 со сменой Generation ID и 1109 со сменой invocationID, в System — 16654 про аннулированный пул RID. То есть предохранители отработали ровно как задумано. В журнале DFS Replication на обоих DC — событие 4614 о том, что SYSVOL инициализирован и ждёт начальной репликации, а парного 4604 нет ни на одном: каждый ждёт другого.

Проверил самое неприятное первым: не устарели ли сами снимки за пределы окна DFSR. У DFSR есть параметр MaxOfflineTimeInDays со значением 60 по умолчанию, и если реплицируемая папка была отключена дольше — служба откажется догоняться и напишет событие 4012, там уже нужен полноценный ручной ресинк. Снимкам было три дня, порог не превышен, повезло. Дальше сверил содержимое SYSVOL руками: на DC01 в \\DC01\C$\Windows\SYSVOL\domain\Policies лежали все 19 каталогов политик, версии GPT совпадали с тем, что показывал Get-GPO -All | Select DisplayName, ModificationTime. Значит данные не потеряны, потеряна только договорённость между службами о том, чья копия главная.

Дальше — процедура авторитетной синхронизации DFSR из следующего раздела. Авторитетным назначил DC01 как держателя PDC Emulator — именно его рекомендует Microsoft как обычно самого актуального по содержимому SYSVOL, а сверка каталогов это подтвердила. Полный прогон занял 25 минут, большая часть — ожидание сходимости репликации AD и два прохода dfsrdiag pollad. В 8:52 на DC01 появилось событие 4602 (SYSVOL инициализирован, член назначен основным), шары вернулись, в 8:58 DC02 отчитался событиями 4614 и 4604. Общий простой групповых политик — около полутора часов, из которых час ушёл на то, чтобы понять, что искать надо не в репликации каталога. Для лаборатории это значило, что первые пробы на пунктах забора маркировали вручную.

Что реально потеряли: изменения, сделанные на контроллерах после снимка и не успевшие уехать к партнёру. Здесь это была одна учётка нового лаборанта, заведённая в субботу, и один сброшенный пароль. Восстановлению из снимка они не подлежат — только заводить заново.

Процедура: возвращаем SYSVOL через авторитетную синхронизацию DFSR

Для DFSR нет ключей BurFlags, как было в FRS. Управление идёт через два атрибута объекта подписки SYSVOL в каталоге: msDFSR-Enabled и msDFSR-Options. Логика простая: msDFSR-Enabled=FALSE выключает подписку, msDFSR-Options=1 помечает её как авторитетную (это и есть аналог D4), после чего подписку включают обратно и заставляют службу перечитать каталог командой dfsrdiag pollad. Все прочие контроллеры проходят тот же цикл, но без msDFSR-Options — для них это D2, неавторитетная синхронизация.

Порядок действий важен: сначала гасим DFSR везде, потом правим атрибуты, потом поднимаем сначала авторитетный контроллер и только затем остальные. Если поднять всё сразу — получите конфликты и файлы в ConflictAndDeleted. Ниже — рабочая последовательность на PowerShell для домена example.local с авторитетным DC01. ADSIEdit тоже годится, но руками в проде я предпочитаю не тыкать.

# Домен example.local, авторитетный источник — DC01 (PDC Emulator)
# Запускать в Windows PowerShell 5.1 с модулем ActiveDirectory:
# в PowerShell 7 у Set-Service/Get-Service нет параметра -ComputerName
$dcs  = 'DC01','DC02'
$auth = 'DC01'

# Шаг 1. Гасим DFSR везде и переводим службу в ручной запуск
foreach ($dc in $dcs) {
    Set-Service -ComputerName $dc -Name DFSR -StartupType Manual
    Stop-Service -InputObject (Get-Service -ComputerName $dc -Name DFSR) -Force
}

# Шаг 2. Правим атрибуты подписки SYSVOL
foreach ($dc in $dcs) {
    $dn  = (Get-ADDomainController -Identity $dc).ComputerObjectDN
    $sub = "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,$dn"
    if ($dc -eq $auth) {
        Set-ADObject -Identity $sub -Replace @{'msDFSR-Enabled'=$false; 'msDFSR-Options'=1}
    } else {
        Set-ADObject -Identity $sub -Replace @{'msDFSR-Enabled'=$false}
    }
}

# Шаг 3. Разгоняем репликацию каталога и убеждаемся, что атрибуты доехали
repadmin /syncall /AdeP
repadmin /replsum

После включения подписки на DC01 и dfsrdiag pollad ждём в журнале DFS Replication событие 4602 — «The DFS Replication service successfully initialized the SYSVOL replicated folder…» с пометкой, что этот член назначен основным (designated primary member). Только увидев его, беритесь за остальные контроллеры: запускаете на них службу, ждёте 4114, возвращаете msDFSR-Enabled=TRUE, делаете dfsrdiag pollad. msDFSR-Options на них не трогаем вообще, а в журнале ждём пару 4614 и 4604 — инициализация и завершение начальной репликации SYSVOL.

# Шаг 4. Поднимаем авторитетный контроллер, ждём 4114
Start-Service -InputObject (Get-Service -ComputerName DC01 -Name DFSR)

# Шаг 5. Возвращаем msDFSR-Enabled=TRUE только на нём и заставляем перечитать AD
$dn  = (Get-ADDomainController -Identity DC01).ComputerObjectDN
Set-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,$dn" `
    -Replace @{'msDFSR-Enabled'=$true}
repadmin /syncall /AdeP
Invoke-Command -ComputerName DC01 { dfsrdiag pollad }
# Ждём в журнале DFS Replication событие 4602 — SYSVOL инициализирован авторитетно

# Шаг 6. Тот же цикл на остальных DC, но БЕЗ msDFSR-Options. Ждём 4614 и 4604.
# Шаг 7. Возвращаем тип запуска службы
foreach ($dc in $dcs) { Set-Service -ComputerName $dc -Name DFSR -StartupType Automatic }

Финальная проверка — по факту, а не по ощущениям: вернулись шары, SysvolReady снова 0x1, dcdiag /test:sysvolcheck /test:advertising проходит на всех DC, и на клиенте gpupdate /force отрабатывает без ошибок, а gpresult /r показывает применённые политики.

Если вы объявили один DC авторитетным, вы обязаны провести неавторитетную синхронизацию на всех остальных. Не «на тех, где проблема», а на всех без исключения — иначе гарантированно поймаете конфликты SYSVOL, которые потом разбирать больнее, чем исходную аварию.
Порядок действий: Процедура: возвращаем SYSVOL через авторитетную синхронизацию DFSR — схема
Порядок действий: Процедура: возвращаем SYSVOL через авторитетную синхронизацию DFSR. Открыть схему в полном размере

Ловушки, на которых спотыкаются из раза в раз

Первая и самая опасная: восстановление контроллера файловым бэкапом или ручным копированием диска. Microsoft прямо помечает это как неподдерживаемый сценарий — «Virtualized domain controllers do not support safe restore of the following: VHD and VHDX files manually copied over existing VHD files; VHD and VHDX files restored using file backup or full disk backup software». Такие операции не меняют VM-Generation ID, предохранители не срабатывают, и вы получаете полноценный USN rollback: контроллер либо уходит в карантин репликации, либо начинает сеять зависшие объекты по всему лесу. Признак — в журнале событие 2171 вместо 2170. Если увидели 2171 после того, как точно что-то восстанавливали, — останавливайтесь и разбирайтесь, дальше будет только хуже.

Вторая: снимок как замена резервной копии. Тут Microsoft тоже не деликатничает: «Virtualized domain controller safe restore is not a replacement for system state backups and the AD DS Recycle Bin». Safe restore не восстанавливает данные — он всего лишь не даёт домену развалиться от отката. Всё, что родилось на откатываемом контроллере после снимка и не успело уехать к партнёру, теряется навсегда. Перед плановым откатом это можно проверить: repadmin /showchanges <партнёр> <DSA Object GUID откатываемого DC> <контекст именования> /statistics покажет количество неотреплицированных изменений. Ноль — откатывайтесь спокойно.

Третья: старый снимок и порог DFSR. Реплицируемая папка, отключённая дольше MaxOfflineTimeInDays (по умолчанию 60 дней), в репликацию сама не вернётся — служба напишет событие 4012 и остановится. То есть снимок контроллера полугодовой давности вам SYSVOL не вернёт даже при живом партнёре. Отдельно проверьте это, если поднимаете DC из давнего архива.

Четвёртая, тихая: гипервизор, который не отдаёт VM-Generation ID. Hyper-V умеет это с Windows Server 2012. VMware vSphere поддерживает VM-Generation ID начиная с 5.0 Update 2 при установленных VMware Tools (требования — в KB 2041872). В QEMU/KVM есть устройство vmgenid, в Proxmox VE оно задаётся параметром vmgenid в конфигурации ВМ и для новых машин генерируется автоматически. Единой гарантии, что ваша платформа меняет идентификатор именно при откате снимка и именно при восстановлении из бэкапа, нет — семантику надо сверять с документацией конкретного гипервизора и проверять экспериментом на тестовом DC. Самый простой тест: откатите тестовый контроллер к снимку и посмотрите журнал Directory Services. Появилось 2170 — механизм работает. Появилось 2171 — откат прошёл мимо механизма. А 2169 при загрузке означает, что идентификатора нет вовсе, и контроллер ведёт себя как на Windows Server 2008 R2: защиты нет, остаётся только карантин USN rollback.

Отдельно про DCCloneConfig.xml: если этот файл забыли в `%windir%\NTDS` или в рабочем каталоге DSA, то при смене VM-Generation ID контроллер воспримет откат как клонирование и попытается переповыситься под новым именем, а при ошибке клонирования или если гипервизор идентификатор не отдаёт — загрузится в Directory Services Restore Mode. Перед снимком проверьте, что такого файла на DC нет.

Регламент: что делать в первую очередь, а на что можно забить

Приоритет номер один — разнести контроллеры по разным хостам и разным дискам. Домен из двух DC на одном гипервизоре — это домен из одного DC с лишними расходами на лицензии. Microsoft это тоже пишет предупреждением, но я видел эту конфигурацию у половины компаний до полусотни мест: «у нас же есть второй контроллер». Есть. На том же самом хосте, который вы и откатываете.

Приоритет номер два — System State backup хотя бы одного контроллера, ежедневно, с хранением 30 дней и с проверкой восстановимости раз в квартал. Снимки виртуалок — это удобно и быстро, но это инструмент отката ошибочного изменения, а не резервная копия каталога. Если у вас есть только снимки — у вас нет резервной копии AD.

Приоритет номер три — простое правило в голове у того, кто нажимает «откатить»: за один раз откатывается ровно один контроллер, второй в это время работает и остаётся источником истины. Если ситуация требует откатить оба (шифровальщик, порча схемы) — это уже не откат, это восстановление леса, и оно идёт по совсем другой процедуре, с изоляцией сети и авторитетным восстановлением с самого начала.

А вот на что можно спокойно забить. На сброшенный пул RID — домен переживёт тысячи таких сбросов. На смену invocationID — это штатное поведение, паниковать при событии 1109 не нужно. На разовые конфликты DFSR после корректно выполненной процедуры D4/D2 — они разбираются потом и без спешки. И на соблазн «сделать всё быстро»: двадцать пять минут аккуратной процедуры дешевле, чем сутки на разгребание расколотого SYSVOL с политиками из трёх разных эпох.

Если корзина Active Directory у вас до сих пор не включена — включите. Большинство откатов контроллеров, которые я разбирал, делались ради возврата удалённых учёток и групп. Корзина закрывает этот сценарий за две минуты и без единого снимка.
Порядок действий: Регламент: что делать в первую очередь, а на что можно забить — схема
Порядок действий: Регламент: что делать в первую очередь, а на что можно забить. Открыть схему в полном размере

Частые вопросы

Почему после отката контроллеров repadmin показывает, что всё в порядке?

Потому что он проверяет репликацию каталога Active Directory, а она после срабатывания предохранителей виртуализации действительно восстанавливается автоматически. SYSVOL реплицируется отдельной службой DFS Replication, и её состояние repadmin не видит вообще. Проверяйте SYSVOL отдельно: наличие шар NETLOGON и SYSVOL, значение SysvolReady в реестре, dcdiag с тестами sysvolcheck и advertising, журнал DFS Replication.

Можно ли просто перезагрузить контроллеры и подождать, пока SYSVOL догонится сам?

Нет. Если все записываемые контроллеры домена были откатаны одновременно, каждый пометил свою реплику SYSVOL неавторитетной и ждёт данные от авторитетного партнёра, которого не существует. Это устойчивый дедлок: ни перезагрузка, ни рестарт службы DFSR, ни время его не разрешат. Нужно вручную назначить один контроллер авторитетным по процедуре D4 из KB 2218556.

Какой контроллер делать авторитетным для SYSVOL?

Как правило — держателя роли PDC Emulator: его содержимое SYSVOL обычно самое свежее, и именно его рекомендует Microsoft. Но перед этим стоит глазами сравнить содержимое папки Policies на всех контроллерах и версии объектов GPO. Если по какой-то причине более полная копия оказалась на другом DC — авторитетным делайте его, роль PDC тут не догма, а эвристика.

Мы восстановили контроллер из бэкапа на уровне дисков. Предохранители сработают?

Зависит от способа. Microsoft прямо относит к неподдерживаемым сценариям VHD/VHDX, скопированные поверх существующих, и диски, восстановленные файловым или дисковым бэкапом: VM-Generation ID при этом не меняется, предохранители не включаются, и вы рискуете получить USN rollback с карантином контроллера или зависшими объектами по лесу. Признак в журнале — 2171 вместо 2170 после восстановления. Восстановление целой ВМ средствами гипервизора или бэкап-системы с поддержкой AD (application-aware) обычно обрабатывается корректно, но это надо проверить на тестовом DC, а не узнать в день аварии.

Что именно теряется при откате контроллера к снимку?

Все изменения, которые возникли на этом контроллере после создания снимка и не успели реплицироваться к партнёрам. Новые учётки, смены паролей, изменения групп — если они родились здесь и никуда не уехали, восстановлению они не подлежат. Перед плановым откатом это проверяется командой repadmin /showchanges с ключом /statistics: она покажет количество неотреплицированных объектов.

У нас всего один контроллер домена. Механизм safe restore меня защитит?

Частично: смена Invocation ID и сброс пула RID произойдут, дубликатов SID вы не получите. Но забирать неавторитетно данные и SYSVOL будет не у кого, и вернуть потерянное после снимка невозможно в принципе. Домен из одного контроллера — это не про откаты, а про регулярный System State backup и проверку восстановления. И, честно говоря, второй контроллер для организации с реальной зависимостью от домена окупается быстрее, чем кажется.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи