Аудит лицензий Microsoft начинается с инвентаризации

Проверка не должна быть первым моментом, когда компания пытается понять, какое ПО Microsoft у нее установлено и на каком основании оно используется. Хорошая подготовка начинается с воспроизводимого снимка среды, реестра приобретенных прав и письменного расчета потребности. Если эти три части нельзя связать строка к строке, папка со счетами не спасет.

Самая опасная привычка - считать активированный продукт лицензированным. Активация подтверждает, что программное обеспечение приняло ключ или цифровое право. Она не доказывает, что организация приобрела нужное количество лицензий, правильно назначила их устройствам или пользователям и соблюла условия виртуализации. До обращения вендора нужно найти именно такие разрывы, исправить их и сохранить след решения.

Зафиксируйте границы и дату снимка

Самостоятельная проверка должна отвечать на вопрос о состоянии среды на конкретную дату, иначе данные из разных недель будут противоречить друг другу. Назначьте дату отсечения, владельца проверки и перечень юридических лиц, площадок, облачных арендаторов и доменов, которые входят в охват. Отдельно запишите исключения и причину каждого исключения.

За охват должен отвечать не системный администратор в одиночку, а руководитель, способный получить данные от закупки, кадров, финансов, безопасности и владельцев сервисов. Администратор знает текущую конфигурацию, но часто не видит счета дочернего общества, договор на аутсорсинг или подписку, которую подразделение купило по корпоративной карте. Укажите по одному ответственному за технический факт, право и деловое решение, чтобы спор не зависал между отделами.

Проверьте организационные изменения за рассматриваемый период. Слияние, выделение юридического лица, перевод работников, аренда оборудования и передача сервиса подрядчику меняют не файлы на диске, а сторону, которая использует и должна подтвердить право. Лицензия, приобретенная одной компанией группы, не становится общей автоматически. Основание для использования аффилированным лицом должно следовать из соглашения, а не из общего владельца бизнеса.

Обычно в охват попадают корпоративные рабочие станции, ноутбуки, физические серверы, виртуальные машины, облачные подписки, удаленные рабочие столы, лаборатории, резервные узлы и устройства филиалов. Не забудьте активы, которыми управляет подрядчик, если организация сохраняет право пользования ПО или контролирует сервер. Личный ноутбук сотрудника тоже требует решения, когда на нем установлены корпоративные приложения или он подключается к лицензируемому серверному сервису.

Создайте паспорт снимка с пятью полями:

• дата и точное время отсечения;
• юридические лица и подразделения в охвате;
• источники технических и закупочных данных;
• ответственные за выгрузки и расчеты;
• известные пробелы с датой их закрытия.

Не меняйте исходные выгрузки после получения. Сохраните их в каталоге только для чтения, вычислите контрольные суммы и работайте с копиями. Тогда через месяц можно доказать, из каких данных получился итог, а не пытаться восстановить вчерашнюю таблицу по переписке.

Установка, активация и право использования не равны

Установка показывает наличие файлов, активация показывает техническое состояние, а право использования следует из договора, заказа и применимых условий продукта. Эти понятия часто склеивают в один столбец «лицензия есть», после чего нормальная сверка становится невозможной.

Microsoft Product Terms прямо указывает, что клиенту нужна лицензия для каждого используемого продукта и отдельно лицензируемой функции, если договор не дает иного права. Там же описаны права на предыдущие версии и более низкие редакции: наличие такого права не превращает установленную старую версию в отдельную приобретенную лицензию. Поэтому строка «Windows Server 2019 активирован ключом от портала» ничего не говорит о количестве покрытых физических ядер, редакции приобретенного продукта и праве переноса.

Ключ продукта также не является запасом лицензий. Документация Microsoft по загрузкам корпоративных продуктов предупреждает: доступ к файлу или ключу в каталоге сам по себе не дает права устанавливать последнюю версию по всем соглашениям. Один MAK-ключ может допускать множество активаций, но это технический предел, а не купленное количество прав.

Для каждой обнаруженной установки держите раздельные признаки: продукт, версия, редакция, канал, состояние активации, назначенный пользователь или устройство, метрика лицензирования и документ-основание. Если основание пока не найдено, ставьте статус «не подтверждено», а не «нелицензионно». Второй вывод требует анализа условий, первый честно описывает качество доказательств.

Сделайте такую же разницу между приобретением и назначением. Счет подтверждает покупку, но еще не показывает, как право закрепили за устройством, пользователем или сервером. Запись в административном портале показывает текущее назначение подписки, но не заменяет заказ и не доказывает право в прошлом периоде. Аудиторская позиция возникает только после соединения этих доказательств.

Не используйте дату установки как дату начала нарушения без дополнительной проверки. Образ мог попасть на диск раньше запуска, устройство могло храниться на складе, а право могло действовать по старому соглашению. И наоборот, удаление записи из списка программ не доказывает, что доступ прекратился: сервис может работать удаленно, компонент может остаться на сервере, а пользователь может иметь право запустить ВМ.

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

Реестр приобретенных прав должен начинаться с договоров и заказов, а не с текущего списка ключей. Соберите соглашения, подтверждения заказов, счета, акты, документы CSP, OEM-сертификаты и сведения о розничных покупках. Для подписок нужны даты начала и окончания, количество мест, арендатор и история изменений; для бессрочных лицензий - версия, редакция, количество, программа закупки и наличие Software Assurance на нужную дату.

Корпоративные лицензии теперь администрируются через Microsoft 365 admin center: Microsoft сообщает, что прежний Volume Licensing Service Center был выведен из эксплуатации в апреле 2024 года. Доступ к данным зависит от роли на конкретном License ID, причем глобальный администратор арендатора не получает права на корпоративные соглашения автоматически. Если нужный договор «не виден», сначала проверьте роли и привязку организации, а не делайте вывод, что лицензий нет.

Минимальная строка реестра прав содержит следующие поля:

• правообладатель и License ID либо номер заказа;
• точное название продукта, версия и редакция;
• метрика и количество приобретенных единиц;
• дата приобретения, срок подписки и статус Software Assurance;
• источник доказательства и владелец документа.

Не складывайте в одну строку покупки с разными условиями. Например, OEM-лицензия Windows, бессрочная корпоративная лицензия и подписка могут давать похожий установленный продукт, но отличаются правом переноса, сроком и способом назначения. Сверка по общему числу «Windows Pro» скрывает риск вместо его оценки.

Сохраните применимую редакцию Product Terms и специальных условий на дату расчета. Текущая страница полезна для текущего состояния, но старое развертывание могло опираться на права, действовавшие в момент покупки или описанные в конкретном соглашении. Архив условий рядом с расчетом убирает спор о том, какую редакцию документа использовал аналитик.

Присвойте каждому доказательству стабильный идентификатор, например ENT-2025-0042, и ссылайтесь на него из матрицы вместо имени файла scan_final2.pdf. В карточке доказательства зафиксируйте путь к оригиналу, юридическое лицо, продавца, номер заказа, позиции и проверившего сотрудника. Если один счет содержит несколько продуктов, разбейте его на строки, но оставьте одну ссылку на оригинал.

Сводная таблица партнера полезна для поиска, однако она вторична. Сверьте ее с первичными заказами и данными портала, а расхождения запросите письменно. Особенно внимательно проверьте возвраты, корректировки количества, замену SKU, продления с измененным планом и покупки на другое название организации. Такие детали объясняют, почему финансовый итог сходится, а право не связывается с нужным объектом.

Инвентаризация должна опираться на несколько источников

Один инструмент управления почти всегда оставляет слепые зоны. Каталог устройств не видит выключенный сервер, агент управления может отсутствовать в лаборатории, а список из Microsoft 365 показывает назначенные облачные лицензии, но не полный состав локальных установок. Сведите хотя бы данные каталога, управления конечными точками, гипервизоров, облака и сетевого обнаружения.

На Windows можно получить базовый список установленного ПО из разделов реестра без вызова Win32_Product. Последний запускает проверку установленных MSI-пакетов и способен вызвать их восстановление, поэтому использовать его для массового опроса я не советую. Такой PowerShell-фрагмент дает пригодную для нормализации заготовку:

$paths = @(
  'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object DisplayName |
  Select-Object @{n='Computer';e={$env:COMPUTERNAME}}, DisplayName, DisplayVersion, Publisher, InstallDate |
  Export-Csv '.\installed-software.csv' -NoTypeInformation -Encoding UTF8

Эта выгрузка не видит все переносимые приложения, компоненты без корректной записи удаления и серверные функции. Дополните ее сведениями об операционной системе и железе, потому что для серверного расчета нужны физические процессоры и ядра:

Get-CimInstance Win32_OperatingSystem |
  Select-Object CSName, Caption, Version, OperatingSystemSKU
Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, Manufacturer, Model, NumberOfProcessors
Get-CimInstance Win32_Processor |
  Select-Object SystemName, SocketDesignation, NumberOfCores

Для виртуальной среды выгрузите не только текущий список ВМ. Нужны хост, кластер, правила миграции, редакция гостевой ОС, число виртуальных ядер и возможные узлы запуска. Если ВМ может перемещаться по всему кластеру, снимок ее сегодняшнего размещения не описывает полный лицензионный сценарий.

Облачные данные собирайте отдельно. В Microsoft 365 admin center раздел Billing > Licenses показывает назначенные и свободные лицензии, а Users > Active users помогает увидеть лицензированных и нелицензированных пользователей. Отчеты об использовании отвечают на другой вопрос: пользовался ли человек сервисом. Нулевая активность не отменяет назначение, а активность помогает найти общие учетные записи, бывших сотрудников и неверно выбранный план.

Снимайте также дату последнего появления устройства и происхождение записи. Два объекта с одинаковым именем могут оказаться переустановленным компьютером и его старой записью, а один физический сервер может присутствовать в каталоге, системе мониторинга и консоли гипервизора. Используйте устойчивый идентификатор, серийный номер или UUID и храните правило дедупликации. Простое удаление дублей по имени незаметно выбрасывает реальные узлы филиалов.

Серверные продукты требуют отдельных способов обнаружения. Проверьте службы, роли ОС, экземпляры баз данных, редакции исполняемых файлов, контейнеры и подключенные компоненты управления. Сопоставьте это с сетевыми подключениями и конфигурацией приложений: пустой список в агенте не доказывает отсутствие SQL Server, если бизнес-система постоянно подключается к неучтенному адресу. Для удаленного доступа нужны списки пользователей и устройств, а не только установленная роль Remote Desktop Services.

Зафиксируйте долю охвата. Если в каталоге 1 200 устройств, агент ответил с 1 050, а 80 записей признаны выведенными из эксплуатации, остаются 70 необъясненных объектов. Их нельзя растворить в примечании «часть компьютеров офлайн». Назначьте владельца каждой группы исключений и добейтесь либо технической выгрузки, либо подтвержденного списания.

Нормализация превращает список ПО в расчет потребности

Сырые названия нельзя сразу сравнивать с заказами, потому что один продукт записывается десятками способов. Сначала приведите издателя, семейство, выпуск, редакцию и компонент к справочнику. «Microsoft 365 Apps for enterprise», «Office 16 Click-to-Run» и отдельная запись языкового пакета не должны превращаться в три независимые потребности.

Добавьте к каждой нормализованной строке модель лицензирования и единицу подсчета: пользователь, устройство, физическое ядро, виртуальное ядро, сервер или доступ. Затем примените условия именно того продукта и соглашения, которое покрывает развертывание. Универсальной формулы «число установок минус число покупок» нет.

Для Windows Server при лицензировании физических узлов нужно знать количество физических ядер и минимумы, заданные условиями продукта. Редакция Standard после полного лицензирования ядер хоста дает ограниченные права виртуализации, а Datacenter покрывает больше виртуальных экземпляров на полностью лицензированном узле. В кластере расчет обязан учитывать каждый хост, где нагрузка может работать. Покупка «16 Core» тоже требует расшифровки: это может быть один пакет на 16 ядер или количество позиций другого размера.

Пользовательские облачные подписки считайте по уникальным людям и правилам конкретного плана, а не по количеству устройств. Серверные CAL считайте отдельно от серверной лицензии и выберите метрику User или Device осознанно. Внешний доступ, мультиплексирование, гостевые пользователи и сервисные учетные записи нельзя автоматически считать бесплатными или платными: решение фиксируют после чтения условий продукта.

Для подписок сравнивайте состояние минимум на дату отсечения и на границах продлений. Текущий остаток мест не отвечает на вопрос, было ли покрытие три месяца назад до сокращения штата или изменения плана. Храните выгрузки заказов и назначений по периодам, а при отсутствии истории обозначайте ограничение расчета прямо в отчете.

Не смешивайте техническое обнаружение продукта с окончательным SKU. Установленная редакция помогает выбрать ветку расчета, но конкретное право может прийти из набора, подписки, права на предыдущую версию или миграционного предложения. Сначала определите потребность независимо, затем примените подходящее право и только после этого считайте баланс. Иначе аналитик незаметно подгоняет классификацию установки под имеющиеся покупки.

Для каждой формулы запишите входные величины, правило, источник правила и результат. Расчет «нужно 96 ядер» без списка хостов и арифметики нельзя проверить. Хорошая рабочая строка выглядит так: 3 хоста × 2 процессора × 16 физических ядер = 96 лицензируемых ядер, после чего отдельной строкой указываются редакция, права виртуализации и приобретенное покрытие.

Типовые расхождения возникают на стыках процессов

Большая часть дефицита появляется не из-за пиратской установки, а там, где закупка, кадровый учет и эксплуатация меняют среду независимо друг от друга. Это не оправдание, а подсказка, куда смотреть сначала.

Бывшие сотрудники часто сохраняют назначенные подписки, а новые получают другой план вручную, хотя группа должна была назначить его автоматически. Microsoft 365 позволяет назначать лицензии пользователям и группам, поэтому выгрузите способ назначения и ошибки групповой обработки. Удаление лицензии требует отдельного решения о доступе к почте и данным, его нельзя выполнять только ради красивого отчета.

На серверах чаще встречаются другие разрывы:

• виртуальная машина получила право мигрировать на непокрытый узел;
• хост заменили на модель с большим числом ядер, а реестр прав не пересчитали;
• редакцию Standard многократно развернули, не долицензировав ядра для дополнительных ВМ;
• OEM-лицензию посчитали переносимой после замены оборудования;
• права на тестовую или разработческую среду предположили без подтверждающей подписки и условий.

Еще один источник ошибок - права на предыдущую версию. Они могут разрешать запуск старого выпуска вместо приобретенного, но расчет все равно строится по лицензии, которая дала это право. Нельзя одновременно использовать одну единицу как покрытие текущего выпуска и как отдельную дополнительную лицензию для старого.

Проверьте пробные и самостоятельно приобретенные подписки. Пользователь может начать пробный сервис или оформить покупку, которую центральная закупка не увидит сразу. Такой аккаунт создает и технический, и договорный вопрос: кто принял условия, кому принадлежат данные, какой план действует после пробного срока. Запрет в политике не устраняет уже созданную подписку, ее нужно найти и оформить решение.

Общие и сервисные учетные записи нельзя считать как обычных работников по одному шаблону. Для каждой запишите владельца, назначенные продукты, способ входа и фактическое назначение. Если лицензия назначена учетной записи только потому, что приложение не умеет работать иначе, это все равно назначение, которое требует анализа условий. Если сотрудник использует общий логин, число учетных записей может, наоборот, занижать число людей с доступом.

Отдельно проверьте SQL Server, Remote Desktop Services, Project, Visio и средства разработчика. Они часто теряются за общим словом «Microsoft», хотя используют разные метрики и дополнительные права доступа. Если команда не может уверенно интерпретировать конкретный сценарий, пометьте его для проверки специалистом, приложив схему архитектуры и факты, а не общий вопрос «мы соответствуем?».

Матрица сверки должна показывать доказательство и дефицит

Итоговая матрица связывает фактическое использование с правами и показывает, как получился остаток. Одна строка на семейство продукта подходит только тогда, когда версия, редакция, метрика и условия одинаковы. Иначе разбейте позицию до уровня, на котором вывод перестает быть двусмысленным.

Используйте такие колонки: Объект, Продукт, Версия, Редакция, Метрика, Потребность, Приобретено, Примененное право, Дефицит/излишек, Доказательство, Владелец, Действие, Срок. Поле «Примененное право» особенно важно для downgrade, Software Assurance, гибридных преимуществ или иных исключений. Без него положительный баланс может опираться на догадку.

Классифицируйте выводы отдельно:

1. подтвержденный дефицит, где факты и условия однозначны;
2. документальный пробел, где покупка вероятна, но первичного доказательства нет;
3. техническая неопределенность, где не хватает сведений о развертывании;
4. спорная интерпретация, требующая письменного заключения;
5. излишек или неиспользуемое назначение, которое можно оптимизировать.

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

Попросите второго специалиста повторить расчет по исходным данным. Если он не получает тот же результат, проблема находится либо в неявном допущении, либо в плохо оформленном правиле. Оба варианта нужно устранить до внешнего запроса.

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

Выборочная проверка годится для оценки качества данных, но не для расчета всего лицензионного положения. Если десять ноутбуков из двадцати проверенных чисты, нельзя умножить результат на парк. Серверы, разработчики, филиалы и руководители получают разное ПО, поэтому выборка скрывает редкие дорогие продукты. Используйте ее, чтобы найти ошибку процесса, затем исправьте источник и пересоберите весь набор.

Исправляйте причину, а не только итоговую цифру

Подтвержденный дефицит нужно закрыть законным способом, но срочная покупка всего из красных строк бывает дорогой ошибкой. Сначала проверьте, можно ли прекратить ненужное использование, исправить назначение, ограничить миграцию ВМ, вернуть устройство в разрешенную конфигурацию или применить уже приобретенное право, которое не попало в реестр. Затем сравните стоимость и ограничения доступных программ закупки.

Каждое исправление оформляйте как изменение с владельцем и доказательством. Для удаления сохраните заявку и повторную инвентаризацию; для переназначения - старое и новое состояние; для покупки - заказ, дату вступления права и связь со строкой дефицита. Не переписывайте исходный снимок так, будто расхождения никогда не было.

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

Нельзя удалять ПО, отключать аккаунты или менять правила миграции без владельца сервиса. Лицензионная чистота не компенсирует остановку бухгалтерии или потерю доступа к почте. Согласованный план исправления должен включать проверку бизнеса, резервный вариант и контрольный снимок после изменения.

Не просите поставщика датировать новый заказ прошлым периодом и не меняйте журналы, чтобы скрыть старое состояние. Новая покупка может закрыть текущую потребность, но ее действие и значение для прошлого периода зависят от договора. Сохраненная хронология и письменная правовая позиция безопаснее красивой таблицы, которой противоречат счета и системные события.

Для каждого устраненного разрыва установите контроль, который не даст ему повториться. Это может быть обязательная проверка лицензий в заявке на новую ВМ, автоматическое снятие назначения после согласованного увольнения, запрет миграции на непокрытый хост или ежемесячная сверка заказов с порталом. Контроль имеет владельца, входные данные и запись о выполнении, иначе через квартал он станет пожеланием.

Репетиция аудита проверяет качество подготовки

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

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

Назначьте одного координатора внешней коммуникации. Администраторы, закупщики и филиалы не должны отправлять разные версии таблиц напрямую. Координатор ведет журнал запросов, согласует толкования с юристом и лицензирующим специалистом, фиксирует, какая версия файла ушла и когда.

Заранее подготовьте форму регистрации запроса: отправитель, договорное основание, охват, период, требуемые поля, срок, владелец ответа и ограничения конфиденциальности. Если запрос неясен, координатор задает письменные уточнения до массовой выгрузки данных. Это не попытка затянуть проверку, а способ не передать лишние сведения и не потратить неделю на таблицу, которая не отвечает поставленному вопросу.

Репетиция должна включать неприятные находки. Подложите строку без счета, выключенный сервер, покупку на другое юридическое лицо и спорную виртуальную машину. Команда должна не угадывать ответ, а правильно зарегистрировать пробел, назначить владельца и показать маршрут решения. Именно поведение при неполных данных отличает управляемую проверку от паники.

Если организации нужна закупка и интеграция ПО Microsoft вместе с инфраструктурой, GSE.kz может собрать решение с учетом существующего оборудования и требований заказчика. Но партнер не заменит ваши первичные документы, перечень развертываний и утвержденных владельцев данных, эти части остаются внутри компании.

После репетиции закройте найденные пробелы и утвердите базовый снимок. Затем встроите сверку в кадровые события, закупку, ввод сервера, изменение кластера и продление подписок. Датированный расчет, который обновляется после каждого такого события, превращает внезапный аудит в обычную проверку записей.