Автоинвентаризация Windows-парка в GLPI 11: GLPI Agent через GPO вместо мёртвого FusionInventory

Меня зовут Евгений Семёнов, я технический директор компании «АйТи Фреш». Пятнадцать с лишним лет мы занимаемся IT-аутсорсингом для московских организаций до 50 рабочих мест, наша инфраструктура живёт на собственных серверах в дата-центре МТС. В обзоре GLPI 11 я объяснял, почему из всех бесплатных ITSM-систем мы остановились именно на ней, а в мануале по развёртыванию GLPI 11 на VPS мы подняли сервер с нуля. Сегодня — самый востребованный у наших клиентов сценарий: как за полчаса раскатать агент инвентаризации на весь Windows-парк через групповые политики и получить живую, самообновляющуюся картину железа, софта и лицензий. И заодно — почему большинство русскоязычных инструкций по этой теме опасно устарели.

Почему инструкции из топа выдачи вас обманут

Наберите в поисковике «инвентаризация GLPI настройка» — и половина статей из первой страницы выдачи предложит вам поставить плагин FusionInventory, скачать FusionInventory Agent и прописать в его конфиге путь к плагину. Не делайте этого. FusionInventory для актуальных веток GLPI — мёртвый проект: с плагином несовместимы уже релизы линейки 10.0.7 и новее, а с одиннадцатой версией он не работает в принципе. Следуя таким мануалам, вы потратите вечер на попытки подружить несовместимые компоненты и решите, что «GLPI — сырое поделие». Хотя на самом деле всё ровно наоборот.

Начиная с десятой версии инвентаризация в GLPI — нативная функция ядра. Никакой плагин не нужен вообще: агент собирает данные о машине и отправляет JSON прямо на эндпоинт сервера http(s)://ваш-glpi/front/inventory.php, а GLPI сам разбирает пакет, создаёт или обновляет карточку компьютера, сверяет серийники и ведёт историю изменений. Роль агента исполняет GLPI Agent — официальный преемник агента FusionInventory от той же команды разработки. Актуальная версия на момент написания — 1.18, вышла 23 июня 2026 года; до неё были 1.17 (май 2026) и 1.16 (февраль 2026, среди прочего добавившая инвентаризацию IED-устройств). Для Windows есть MSI-пакет x64, для Linux — deb, rpm и snap, поддерживается и macOS.

Чтобы расставить точки над i, сведу отличия двух миров в одну таблицу:

Дальше в статье — только новый мир. Если у вас в проде ещё крутится связка GLPI 9/10 + FusionInventory, не переживайте: в предпоследнем разделе я разберу порядок миграции без потери накопленных данных.

Как устроен GLPI Agent

Прежде чем массово что-то раскатывать, полезно понимать, что именно поедет на каждую машину. GLPI Agent — компактная служба, которая по расписанию опрашивает операционную систему и отправляет результат на сервер. Никаких «звонков домой» разработчику, никакой телеметрии наружу — только ваш агент и ваш сервер.

Что агент собирает с машины

Полнота сбора — главное, что отличает автоинвентаризацию от таблички в Excel, которую «забыли обновить в марте». С каждой Windows-машины агент вытаскивает:

• Железо: модель и серийник самой машины, процессор, объём и раскладку памяти по слотам, диски, видеокарты — и, что особенно ценно, мониторы с серийными номерами по EDID. Когда у клиента «пропал» монитор при переезде между кабинетами, именно EDID-серийники позволили за минуту выяснить, к какому системнику он теперь подключён;
• Софт: полный список установленных программ с точными версиями — основа и для учёта лицензий, и для ответа на вопрос «на скольких машинах ещё стоит уязвимый браузер»;
• Локальные учётные записи — быстро подсвечивает машины, где кто-то когда-то завёл локального админа «на минутку»;
• Антивирус — какой продукт стоит и в каком состоянии;
• Сетевые интерфейсы — MAC, IP, скорости; удобно для сверки с DHCP и поиска «неизвестных» устройств.

Режимы работы: служба или разовый запуск

Основной режим — служба Windows: агент висит в фоне и по внутреннему расписанию (по умолчанию раз в сутки, интервал регулируется) отправляет свежий срез на сервер. Ставится это одним параметром установщика — EXECMODE=1. Альтернатива — запускать агент разово из планировщика задач: процесс отрабатывает, шлёт отчёт и завершается. Мы почти всегда выбираем службу: она переживает перезагрузки, не требует внешнего пинка и сама решает, когда машине пора отчитаться. Планировщик оставляем для специфических случаев вроде терминальных серверов, где хочется жёстко контролировать момент запуска.

Включаем приёмник на стороне GLPI 11

На сервере всё сводится к одному экрану: Администрирование → Инвентаризация (Administration → Inventory). Там включается сам приём данных от агентов и задаётся токен доступа — строка, которой агенты подтверждают право отправлять пакеты. Без включённого приёмника агент будет стучаться в /front/inventory.php и получать отказ, а вы — недоумевать, почему в консоли пусто. На этой же странице настраивается, какие категории данных импортировать: можно, например, не тащить в базу локальные учётки, если для вас это лишний шум.

Массовое развёртывание через GPO

Ставить агент руками на полсотни машин — занятие для стажёра со свободной неделей. В домене Active Directory та же задача решается групповой политикой за один вечер, причём новые машины, попадая в домен, будут получать агента автоматически — про инвентаризацию можно будет просто забыть.

MSI-пакет и параметры msiexec

Установщик GLPI Agent — обычный MSI, и все ключевые настройки передаются ему параметрами командной строки. Документированный набор, которым мы пользуемся: SERVER — адрес приёмника, RUNNOW=1 — отправить первый отчёт сразу после установки, не дожидаясь планового цикла, TAG — произвольная метка машины (мы пишем туда филиал или площадку — по тегу потом строятся фильтры и правила распределения по сущностям GLPI), EXECMODE=1 — работа службой. Готовая строка для копипасты:

msiexec /i GLPI-Agent-1.18-x64.msi /quiet SERVER="https://glpi.example.ru/front/inventory.php" RUNNOW=1 TAG="office-msk"

Обратите внимание: в SERVER указывается полный путь до /front/inventory.php, а не просто адрес сайта. Это самая частая опечатка, из-за которой «агент поставился, но ничего не приходит».

Software Installation или Scheduled Task: что выбираем и почему

Раскатать MSI через GPO можно двумя путями, и у каждого своя цена.

Вариант A — классический Software Installation. В политике (Computer Configuration → Policies → Software Settings) публикуется MSI, лежащий на сетевой шаре — SYSVOL или DFS, — и Windows ставит его при загрузке машины. Способ проверенный, но с существенным ограничением: параметры командной строки в него не передать. Чтобы зашить SERVER и TAG, придётся готовить mst-трансформ или править таблицы MSI в Orca — то есть пересобирать пакет при каждой смене параметра и каждом релизе агента. Работает, но негибко.

Вариант B — наш выбор: GPP Scheduled Task или startup-скрипт с полной строкой msiexec. Групповая политика создаёт на машинах задачу (или отрабатывает скрипт при загрузке), которая проверяет установленную версию агента и при необходимости выполняет ту самую строку из блока выше. Все параметры и номер версии живут в одном месте — в тексте команды внутри политики. Вышел GLPI Agent 1.19 — кладём новый MSI на шару, меняем цифру в команде, и парк обновляется сам. Для меня это решающий аргумент: за годы практики агент обновляется куда чаще, чем хочется пересобирать трансформы.

Честности ради: вариант A уместен там, где параметры заданы раз и навсегда, а админ не дружит со скриптами — mst делается один раз, и дальше всё само. Но при регулярных обновлениях и нескольких площадках с разными TAG вариант B выигрывает с разгромным счётом.

Проверяем охват: агенты против списка машин из AD

Раскатали политику — не спешите рапортовать об успехе. Главная метрика внедрения — охват: сколько машин реально отчиталось против того, сколько их числится в домене. Здесь красиво срабатывает связка с LDAP-синхронизацией: GLPI умеет тянуть список компьютеров из Active Directory, и контраст между «в AD видим 52 машины» и «агентов отчиталось 44» сразу указывает, где искать дыры. По нашему опыту, недостающие машины делятся на три предсказуемые категории:

• Машины, которые месяцами не включаются. Резервный системник главбуха, комп в переговорке, «станция для сканера» — они получат агента при первом же включении, но до тех пор будут висеть в списке отсутствующих. Мы помечаем такие машины в GLPI отдельным статусом, чтобы они не портили статистику;
• Ноутбуки удалёнщиков. Устройство в домене, но в офисе появляется раз в квартал — GPO до него просто не доезжает. Таким сотрудникам мы ставим агент разово руками или самораспаковывающимся пакетом, благо дальше он работает самостоятельно;
• Агент за NAT. Классическая грабля: сервер GLPI опубликован только во внутренней сети, а ноутбук уехал домой — и агент стучится в недостижимый адрес. Решается публикацией приёмника наружу по HTTPS с тем самым токеном доступа либо доступом через корпоративный VPN. Второй вариант мы любим больше: поверхность атаки меньше.

Linux-серверы и то, что агентом не покрыть

Windows-парк — обычно 90% машин у наших клиентов, но оставшиеся 10% — как правило, самое ценное: Linux-серверы с базами и шлюзами плюс сетевое железо. Бросать их вне инвентаря нельзя.

Агент на Linux: пакет и конфиг

Для Linux GLPI Agent ставится штатным пакетным менеджером — apt install glpi-agent на Debian/Ubuntu или dnf install glpi-agent на RHEL-семействе (есть и snap). Настройка — текстовый конфиг /etc/glpi-agent/agent.cfg, где нам важны те же два параметра, что и в MSI:

# /etc/glpi-agent/agent.cfg
server = https://glpi.example.ru/front/inventory.php
tag = srv-linux-msk

# перезапускаем агент, чтобы перечитал конфиг,
# и он отчитается по своему расписанию

Работать агент может как постоянная служба или запускаться периодически — через cron либо systemd-timer. Для серверов, которые никогда не выключаются, мы предпочитаем таймер: меньше постоянно висящих процессов, а суточной периодичности отчётов для серверной инвентаризации более чем достаточно.

SNMP-обнаружение: принтеры, коммутаторы и счётчики страниц

Принтер или коммутатор агентом не покроешь — туда его не поставить. Для такого железа у GLPI Agent есть задачи netdiscovery и netinventory: один из агентов в сети (мы назначаем на эту роль сервер или надёжную рабочую станцию) сканирует заданные диапазоны адресов, находит устройства и опрашивает их по SNMP. В инвентарь прилетают принтеры, МФУ, коммутаторы с моделями, серийниками и прошивками.

Отдельный приятный бонус — счётчики страниц с принтеров и МФУ. GLPI хранит их историю, и внезапно у вас появляется ответ на вопрос, который бухгалтерия задаёт годами: сколько реально печатает каждый отдел и во что обходится содержание конкретного аппарата. У одного клиента именно эти счётчики показали, что «экономичный» струйник в рознице по стоимости отпечатка обгонял офисный лазерник втрое — аппарат заменили и стали экономить на расходниках каждый месяц.

Учёт лицензий поверх автоинвентаря

Инвентарь софта без учёта лицензий — половина пользы. Ну, знаете вы, что Office стоит на 23 машинах. А сколько у вас куплено? Ответ обычно ищут в переписке с поставщиком трёхлетней давности. GLPI закрывает этот разрыв разделом Управление → Лицензии: заводите каждую закупку — Windows, Office, 1С, антивирус, КриптоПро — с количеством, датами и документами, привязываете её к конкретному софту из автоинвентаря, и дальше система сама сводит баланс.

Магия в счётчике «куплено N — установлено M». Агенты ежедневно обновляют список установленного ПО, GLPI сопоставляет его с заведёнными лицензиями, и картина «куплено 20, установлено 23» подсвечивается сама — без ручных сверок. Это готовый аргумент в разговоре с директором: не абстрактное «надо бы докупить лицензий», а конкретное «вот три машины сверх купленного, вот стоимость легализации, вот риски проверки». В обратную сторону работает не хуже: «куплено 30, установлено 19» — повод не продлевать лишнее при следующей закупке.

Вторая недооценённая функция — напоминания об истечении. Подписки на антивирус, сертификаты, годовые лицензии имеют свойство заканчиваться в самый неудобный момент. Дата окончания, заведённая в карточку лицензии, превращается в уведомление заранее — и продление становится плановой задачей, а не пожаром «у нас антивирус превратился в тыкву, а бюджет согласовывать неделю».

Кастомные типы активов GLPI 11 в деле

Агент видит только то, что подключено к компьютеру и отвечает по SNMP. Но у любой конторы есть имущество, которое тоже хочется учитывать: токены СКЗИ для банк-клиентов и ЭЦП, SIM-карты корпоративной связи, терминалы сбора данных, ключи от серверной, наконец. Раньше под это ставили плагины Generic Object или Fields — сомнительной свежести и с риском отвала при каждом апгрейде. В GLPI 11 наработки этих плагинов влиты в ядро: конструктор собственных типов активов доступен из коробки в разделе Настройки → Типы активов.

Живой пример с наших внедрений — тип «Рутокен». Токенов с подписями у типичного клиента до 50 РМ наберётся с десяток: банк-клиенты, ЭДО, госпорталы. Заводим кастомный тип с полями «владелец» (связь с пользователем из LDAP), «какой сертификат записан», «срок действия» — и хаос вида «а у кого сейчас токен от банка?» превращается в справочник с историей перемещений. Бонусом — уведомление о подходящем сроке сертификата: перевыпуск ЭЦП перестаёт быть сюрпризом в день сдачи отчётности.

По той же схеме мы описываем SIM-карты (номер, тариф, в каком устройстве, кто пользуется) и ТСД на складах. Правило простое: всё, что жалко потерять и что кому-то выдаётся, заслуживает карточки в GLPI — независимо от того, умеет ли это железо отчитываться самостоятельно.

Миграция с GLPI 9/10 + FusionInventory

Теперь обещанное — что делать, если у вас прод на старой связке. Прыгать с GLPI 9 сразу на 11 нельзя, порядок движения такой:

1. Полный бэкап базы и файлов — перед каждым мажорным шагом, без исключений. Мажорный апгрейд GLPI необратим, откат — только из копии;
2. Апгрейд до свежей 10.0.x. Обновляете код, прогоняете миграцию схемы командой php bin/console db:update, проверяете, что интерфейс жив и данные на месте;
3. Включение нативного inventory в Администрирование → Инвентаризация — с этого момента сервер готов принимать данные от нового агента;
4. Замена агентов на парке. Та же GPO, что ставила FusionInventory Agent, теперь удаляет его и ставит GLPI Agent строкой msiexec из раздела про GPO. Карточки компьютеров агент подхватывает существующие — сверка идёт по серийникам и именам, дубли при аккуратной настройке правил импорта не плодятся;
5. Только теперь — прыжок на 11: снова бэкап, снова обновление кода и php bin/console db:update.

Что теряется по дороге: часть сторонних плагинов, не переживших смену мажорной версии, — перед стартом пройдитесь по своему списку и проверьте совместимость каждого с 11. Специфические настройки самого FusionInventory (правила задач, расписания) придётся воспроизвести в терминах нативной инвентаризации заново — автоматической конвертации нет. А вот накопленные данные — компьютеры, история, документы, заявки — переезжают штатными миграциями.

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

Итог: что получает контора до 50 рабочих мест

Соберу картину целиком. После одного вечера настройки — приёмник, GPO, пара Linux-конфигов и SNMP-диапазоны — компания получает:

• Живую карту парка без ручного труда. Каждая машина ежедневно отчитывается сама; Excel-файл «Инвентаризация_2024_ФИНАЛ_v3», который врал уже в момент создания, отправляется на пенсию;
• Ответ на вопрос «что у нас есть» за 30 секунд. Сколько машин, на чём они работают, где стоит уязвимая версия софта, у кого меньше 8 ГБ памяти — любой из этих вопросов закрывается фильтром в списке, а не обходом кабинетов;
• Базу для бюджетирования апгрейдов. Возраст машин, конфигурации и счётчики печати превращают «надо бы обновить технику» в конкретный план: какие 6 машин меняем в этом квартале и почему;
• Порядок в лицензиях и «неучтёнке» — от счётчика «куплено/установлено» до карточек токенов и SIM-карт.

Теперь цифры из нашей практики. До внедрения инвентаризация у типичного клиента на 30–50 машин съедала у приходящего специалиста часов шесть в месяц: сверки, обходы, уточнения «а что стоит у Марины из бухгалтерии». После — практически ноль: данные обновляются сами, инженер тратит минуты на просмотр отклонений. Шесть сэкономленных часов в месяц по ставкам аутсорсинга окупают всю настройку за первый же квартал — а побочные эффекты вроде предотвращённой закупки лишних лицензий обычно окупают её ещё до конца первого месяца.

Если хочется такой же порядок в своём парке, но заниматься GPO и токенами некому — мы в «АйТи Фреш» разворачиваем GLPI с автоинвентаризацией под ключ: сервер, агенты на весь парк, SNMP-обнаружение, учёт лицензий и обучение ответственного. Напишите в Telegram @ITfresh_Boss или позвоните +7 903 729-62-41 — посмотрим ваш парк и скажем, сколько времени займёт наведение порядка именно у вас.