Windows Server CAL: когда нужны и как вести учет без ошибок

Зачем вообще разбираться с Windows Server CAL

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

CAL редко вспоминают в момент внедрения. Домен поднимают «для порядка», файловую шару делают «временно», удаленный доступ включают «пока не купили VPN». Технически все работает, а лицензирование откладывается, пока не появляется вопрос от закупок, аудитора или руководства: «Сколько нам нужно и почему?»

Чем это может обернуться

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

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

Разобраться заранее полезно не только администраторам. Закупкам проще сравнивать модели (User CAL или Device CAL), финансам - прогнозировать затраты, юристам - понимать, какие права реально приобретены, а руководству - снижать риск остановки важных работ из-за лицензий.

Если у вас есть AD, файловые ресурсы, удаленные рабочие места или серверные приложения, тема CAL рано или поздно станет практической. Лучше, чтобы это произошло по вашему плану, а не в «пожарном режиме».

Базовые понятия: серверная лицензия и CAL

Лицензия Windows Server и Windows Server CAL - это разные вещи.

Серверная лицензия относится к самому серверу: она дает право установить и использовать ОС на оборудовании (или в виртуальной среде). CAL (Client Access License) относится к доступу: она подтверждает право пользователей или устройств подключаться к сервисам Windows Server.

Проще запомнить так: серверная лицензия отвечает на вопрос «можно ли запускать Windows Server здесь?», а CAL - «кто имеет право пользоваться тем, что этот сервер дает». Даже если у вас один небольшой сервер, доступ сотрудников к домену, файловым папкам или принт-сервису обычно требует CAL.

Есть два основных варианта CAL:

• User CAL - привязана к человеку и подходит, когда один сотрудник работает с нескольких устройств.
• Device CAL - привязана к конкретному устройству и удобна, когда много людей по очереди используют одни и те же компьютеры.

Выбор часто понятен на бытовых примерах. Если в офисе у каждого сотрудника есть рабочий ПК плюс ноутбук, а иногда еще телефон для почты, чаще выигрывает User CAL. Если это сменная работа, класс в учебном центре или стойка оператора с «общими» ПК, обычно логичнее Device CAL.

Отдельно встречается External Connector. Его рассматривают, когда к серверу должны регулярно подключаться внешние пользователи (не ваши сотрудники и не подрядчики в роли персонала), и считать CAL на каждого такого пользователя неудобно. Это не универсальная замена CAL: важно заранее определить, кто считается «внешним» для вашей организации.

Редакция Windows Server (например, Standard или Datacenter) сама по себе не отменяет CAL. Редакции влияют на возможности и правила развертывания, но право доступа пользователей и устройств к базовым сервисам подтверждается CAL отдельно. При этом некоторые сценарии добавляют еще один слой лицензий (например, для удаленных рабочих мест), но это уже отдельная тема.

Когда CAL требуются: простое правило и границы

Самое простое правило такое: если пользователь или устройство обращается к службам Windows Server по сети, обычно нужна Windows Server CAL. Не важно, стоит ли сервер в офисе или в дата-центре, физический он или виртуальный. Важен сам факт доступа к серверным функциям.

Под «доступом» чаще всего понимают не «зашел в комнату с сервером», а использование его как сервиса: вошли в домен, открыли общую папку, распечатали на сетевой принтер, запустили приложение, которое работает на Windows Server.

Типовые случаи, когда CAL почти всегда нужны: вход в домен и проверка учетных данных (Active Directory), доступ к файловым ресурсам и общим папкам, сетевая печать, использование приложений, которые работают на Windows Server и обслуживают пользователей по сети, а также обращение к базовым службам (например, DHCP/DNS) как части корпоративной сети.

Границы не всегда очевидны. Если на Windows Server размещен публичный сайт для анонимных посетителей из интернета, это обычно рассматривают отдельно от «внутреннего» пользовательского доступа. Но как только появляются аутентификация, доступ «для сотрудников» или работа через доменные учетные записи, CAL почти всегда становятся обязательными.

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

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

AD и файловые сервисы: где CAL обычно забывают

Путаница с Windows Server CAL чаще всего случается там, где сервер «просто работает»: домен, общие папки, принтеры. Кажется, что раз вы не покупали отдельное серверное приложение, то и дополнительных прав доступа не нужно. Но CAL покрывают именно доступ пользователей или устройств к службам Windows Server.

Active Directory (AD DS): доступ есть, даже если «только вход в домен»

Если пользователь или устройство входит в домен, проходит проверку учетных данных, получает групповые политики (GPO), обращается к контроллеру домена за билетами Kerberos или обновляет пароль, это уже доступ к службам Windows Server. То же самое касается сценариев, где AD «на фоне»: Wi‑Fi по доменной учетке, прокси с интеграцией, компьютеры, которые при включении применяют политики.

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

Файловые службы (SMB) и печать: «базовые» не значит «без CAL»

Общие папки, домашние директории, сетевые диски, скан в папку, профили пользователей, а также роль печати и принтеры через сервер - все это доступ к Windows Server. Если к шару подключается не человек, а устройство (например, МФУ кладет сканы в SMB-папку), это тоже нужно учесть.

Из учета чаще всего выпадают общие терминалы в цехе или на складе, «гостевые» ПК, устройства с общей учетной записью, МФУ, камеры и мини-ПК, которые пишут или читают с SMB, а также подрядчики, подключающиеся к ресурсам компании.

Пример: 1 файловый сервер, 120 сотрудников и 30 общих терминалов

Логика такая: сначала решите, что вы лицензируете - пользователей или устройства. Если у 120 сотрудников несколько устройств (например, ноутбук плюс ПК), User CAL часто проще. А 30 общих терминалов, которыми пользуются разные смены, обычно выгоднее закрывать Device CAL, потому что лицензируется сам терминал, а не каждый человек, который к нему подходит.

Главное правило для AD и файловых сервисов: считайте не «серверы», а всех, кто реально обращается к их службам, включая устройства и сценарии «в фоне».

RDS и удаленные рабочие места: отдельный слой лицензий

Здесь часто возникает путаница: Windows Server CAL и RDS CAL - это разные права. Первая дает право пользователю или устройству обращаться к службам Windows Server (например, к файловым ресурсам, печати, AD). RDS CAL дает отдельное право работать именно с удаленными рабочими сессиями или опубликованными приложениями через Remote Desktop Services.

Обязанность по RDS CAL появляется не из-за самого факта подключения к серверу по сети, а когда вы используете RDS-сценарии: вход в сеанс на Session Host, запуск опубликованного приложения, подключение через RD Gateway к RDS-пулу. Если администратор разово заходит по RDP для управления сервером (админские подключения), это не то же самое, что выдача удаленных рабочих мест сотрудникам.

Фраза «у нас просто удаленный доступ к серверу» почти всегда означает одно из двух: либо администрирование (и тогда речь о минимальном числе админских подключений), либо рабочее место сотрудника в удаленной сессии (и тогда нужны RDS CAL). Отличить просто: если человек работает в «удаленном рабочем столе» как в обычном ПК и делает свою работу, это RDS.

Выбор между User RDS CAL и Device RDS CAL обычно решают по тому, кто к чему привязан. В сменных сценариях (колл-центр, учебный класс, пост охраны) чаще выгоднее Device RDS CAL. Когда один человек заходит с разных мест и устройств (например, врачи, менеджеры), обычно подходит User RDS CAL.

В проекте важно проверить не только «сколько одновременных подключений», но и сколько уникальных пользователей или устройств реально используют RDS. Одновременность важна для мощности сервера, но лицензирование RDS CAL привязано к пользователям или устройствам, а не к пиковому числу сессий.

Серверные приложения: CAL и лицензии ПО не одно и то же

Путаница часто появляется, когда бизнес покупает «лицензию на приложение» и считает, что этим закрыт доступ к серверу. На практике лицензия приложения и Windows Server CAL решают разные задачи: первая дает право использовать конкретное ПО, вторая - право пользователям или устройствам обращаться к службам Windows Server.

Представьте сценарий: бухгалтерия работает в учетной системе, которая установлена на Windows Server. У одних сотрудников толстый клиент на ПК, у других - веб-интерфейс, у третьих - тонкий клиент через терминальный доступ. Если приложение крутится на Windows Server и пользователи так или иначе подключаются к файловым ресурсам, службе печати, доменной авторизации или другим серверным функциям, вопрос CAL все равно возникает, даже если «приложение лицензировано».

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

Упрощенное правило: лицензия приложения отвечает за функционал приложения, а CAL - за сам факт доступа к Windows Server. Если пользователь открывает программу, которая берет данные с сервера, сохраняет файлы на сервере, печатает через сервер или проходит вход через домен, он использует сервисы Windows Server. Значит, помимо лицензии приложения, могут требоваться Windows Server CAL.

Отдельно стоит помнить про RDS: если доступ к приложению идет через удаленный рабочий стол (терминальный сервер), к Windows Server CAL добавляется еще слой лицензирования - RDS CAL.

Службы, которые «тянут» CAL незаметно

CAL часто забывают, потому что подключение выглядит как «просто работа программы». На деле CAL может понадобиться из-за зависимостей: авторизация через Active Directory (вход под доменной учетной записью), хранение документов или выгрузок на сетевых папках, печать через сервер печати, доступ к данным на сервере даже при тонком клиенте (например, web).

Перед покупкой полезно задать поставщику приложения несколько прямых вопросов: будет ли система требовать доменную авторизацию, где будут лежать файлы и база, как пользователи подключаются (локально, по сети, через RDS), какие роли Windows Server будут задействованы. Это помогает заранее разделить: что покрывает лицензия приложения, а что нужно докупить как CAL (и, при необходимости, RDS CAL).

Как посчитать CAL на практике: пошаговый подход

Подсчет CAL проще, если не пытаться «угадать по штату». CAL нужны не за факт покупки сервера, а за доступ к его сервисам. Поэтому сначала фиксируем, кто и к чему реально подключается, а уже потом считаем.

Рабочая схема, которую можно повторить почти в любой организации:

• Опишите сервисы на каждом сервере: AD (аутентификация), файловые шары, печать, RDS, а также любые приложения, которые используют серверные роли.
• Составьте список потребителей доступа: группы пользователей, типы устройств, филиалы, подрядчики, терминалы на складе, кассы.
• Для каждого сценария выберите модель: User или Device. Не смешивайте выбор «по привычке».
• Посчитайте количество и сразу запишите допущения: что считается «пользователем», какие устройства входят в периметр, учитываете ли внешних подрядчиков, как считаете общие аккаунты.
• Сверьте расчет с ростом и сезонностью: сменная работа, временные сотрудники, проектные команды, расширение филиалов.

Как выбрать User или Device

User CAL обычно выгоднее, когда один человек заходит с нескольких устройств (офисный ПК, ноутбук, телефон). Device CAL чаще выгоднее там, где много людей используют одни и те же рабочие места (смены, колл-центр, пост охраны, учебные классы).

Маленький пример расчета

Есть домен и файловый сервер. В офисе 60 сотрудников, у каждого по два устройства, и еще 10 общих ПК в переговорных. Для доступа к AD и файлам логично сравнить: 60 User CAL против 70 Device CAL (60 персональных рабочих ПК + 10 общих). Часто выигрывает User.

Дальше проверьте отдельные слои. Если 15 сотрудников работают через терминальные сессии, к базовым Windows Server CAL добавятся RDS CAL на этих 15 пользователей (или на устройства, если терминалы общие). Главное - не терять связь между цифрой и допущением: тогда проверка и закупка проходят спокойнее.

Типичные ошибки и ловушки в лицензировании CAL

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

Вторая ловушка - считать только сотрудников по списку HR. Доступ получают не только «люди», но и общие рабочие места: стойка регистрации с одним ПК на смену, учебный класс, складской терминал, киоск, касса. Если такими точками пользуются разные люди по очереди, часто выгоднее считать по устройствам, но это нужно заранее решить и зафиксировать.

Еще одна проблема - хаотично смешивать User CAL и Device CAL. Это не «как получится»: выберите правило (например, офис по пользователям, производство по устройствам) и придерживайтесь его. Иначе на проверке сложно объяснить, почему часть доступа считается «по людям», а часть «по железу».

Отдельный слой путаницы - RDS. Windows Server CAL и RDS CAL - не одно и то же. Если сотрудники заходят на сервер по удаленному рабочему столу для полноценной работы (сеансы RDS), обычно нужны оба типа лицензий: базовые CAL на доступ к серверу и RDS CAL на удаленные сеансы.

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

Короткая проверка, где чаще всего появляются «дыры»:

• общие ПК, терминалы и сменные рабочие места
• RDS и публикация приложений
• сервисные учетные записи, через которые работают приложения
• подрядчики, временный персонал, внешняя поддержка
• отсутствие зафиксированного выбора User vs Device

Пример: в компании 60 сотрудников, но есть 10 общих ПК на производстве в 3 смены. Если посчитать только «60 человек», можно недоучесть доступ с общих устройств или, наоборот, переплатить, если логичнее закрыть цех Device CAL и оставить офис на User CAL.

Как оформить реестр учета CAL: простой шаблон

Реестр учета CAL нужен, чтобы у ИТ и закупок была одна версия правды: что куплено, к чему относится, сколько доступно и кто за это отвечает. Когда начинается аудит, смена подрядчика или расширение инфраструктуры, именно реестр быстрее всего снимает вопросы.

Проще всего вести его в таблице или в вашей ITSM, но с одинаковыми полями. Минимальный набор колонок:

• Продукт (например, Windows Server 2022) и роль или сервис (AD, файловый сервер, RDS)
• Тип CAL (Windows Server CAL, RDS CAL)
• Модель: User или Device
• Количество (куплено, доступно, зарезервировано)
• Дата покупки и поставщик
• Документ-основание (счет, акт, договор, номер заказа)
• Владелец сервиса (ФИО или роль: админ AD, владелец RDS, руководитель ИТ)

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

Обновляйте реестр по событиям, а не «когда вспомнили». Хорошо работает короткий регламент: прием сотрудника, покупка или вывод ПК, подключение нового филиала, запуск RDS или нового серверного приложения. Если у вас есть календарь закрытия месяца, добавьте проверку реестра туда.

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

Реалистичный пример: компания с доменом, файлами и RDS

Представим компанию: 1 головной офис и 2 небольших филиала. Есть домен (AD) для учетных записей, один файловый сервер с общими папками для всех, и отдельный сервер RDS, через который бухгалтерия запускает 1С и пару рабочих приложений.

По людям и устройствам картина такая: в офисе 35 сотрудников с личными ноутбуками. В филиалах по 8 сотрудников, но рабочие места «общие»: 6 стационарных ПК на смену. Бухгалтеров 6, и они работают через RDS из офиса и иногда из дома.

Для базового доступа к AD и файловым ресурсам нужны Windows Server CAL. Здесь логика обычно такая: офисным сотрудникам удобнее выдавать User CAL (один человек, много устройств). А для общих компьютеров в филиалах выгоднее Device CAL (одно устройство, разные люди).

Отдельный слой - RDS. RDS CAL нужны только тем, кто подключается к Remote Desktop Services. В этом примере это 6 бухгалтеров. Остальным сотрудникам, которые просто заходят в домен и на файловые папки, RDS CAL не требуются.

Чтобы это не потерялось в учете, в реестре лицензий делайте записи раздельно, с пояснением расчета. Например:

• Windows Server User CAL - 35 шт. (офисные пользователи)
• Windows Server Device CAL - 12 шт. (6 ПК в каждом из 2 филиалов)
• RDS User CAL - 6 шт. (бухгалтерия, доступ через RDS)

Перед закупкой стоит задать руководителю несколько вопросов, чтобы не купить «впритык»:

• Планируется ли рост штата в ближайшие 6-12 месяцев?
• Будут ли новые филиалы или дополнительные смены?
• Сколько людей реально работают удаленно и как часто?
• Появятся ли общие рабочие места в офисе (колл-центр, ресепшен)?
• Планируются ли новые серверные роли или перенос приложений на RDS?

Так реестр будет отражать не только цифры, но и логику, которую проще защитить на проверке.

Чеклист и следующие шаги для закупки и аудита

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

Короткая самопроверка по инфраструктуре:

• Перечислите роли и сервисы: AD DS, файловые ресурсы, печать, RDS, приложения (1С, SQL, терминальные фермы).
• Отметьте, кто реально подключается: сотрудники, подрядчики, учетные записи сервисов, внешние пользователи.
• Сверьте числа: активные пользователи в домене, устройства на учете, удаленные подключения в RDS.
• Проверьте границы доступа: есть ли общие папки, куда заходят «все», и нет ли неучтенных филиалов или сменных рабочих мест.
• Разделите доступ по типам: обычный доступ к Windows Server и отдельный слой для RDS.

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

Следующие шаги для спокойной закупки и аудита:

• Соберите подтверждения: счета, акты, лицензии, переписку, привязку к юрлицу и подразделениям.
• Утвердите правило пересмотра расчета: раз в квартал и каждый раз при изменениях (новый филиал, RDS, переход на новые приложения).
• Заложите запас на рост и сезонных пользователей, но фиксируйте, почему он нужен.
• При планируемом обновлении серверов заранее включите лицензии и поддержку в проект. Если нужно, обсудите расчет с интегратором и поставщиком серверов, например с GSE.kz, чтобы «железо», роли и лицензии сошлись по плану.

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