Зависают и пропадают лицензии 1С в файловой базе через IIS и терминал: подробное руководство по поиску утечек и решению проблемы

← На главную

Рано или поздно многие системные администраторы и специалисты 1С сталкиваются с крайне неприятной ситуацией: в небольшой компании развернута файловая информационная база (например, «1С:Управление торговлей 11» или «1С:Бухгалтерия»), опубликованная на веб-сервере IIS для удаленных сотрудников, а часть пользователей работает локально через терминальный сервер (RDS). При этом в наличии имеется фиксированный пул программных лицензий (например, 10 однопользовательских пин-кодов). В разгар рабочего дня пользователи начинают жаловаться на нехватку лицензий, хотя реальное количество работающих сотрудников гораздо меньше номинального номинала. Лицензии уходят в «никуда» и освобождаются очень медленно, а перезагрузка всего сервера — крайне нежелательная мера.

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

Причина 1. Потеря связи веб-клиентов и некорректная настройка файла default.vrd

Когда удаленный пользователь работает с базой через веб-клиент (браузер) или тонкий клиент по протоколу HTTP/HTTPS, веб-сервер IIS связывает его с конкретным сеансом 1С с помощью файлов cookies. Если у пользователя нестабильный интернет-канал, происходят кратковременные обрывы связи или браузер по какой-то причине сбрасывает cookies (из-за политик безопасности или отсутствия SSL-шифрования), то при очередном запросе или обновлении страницы (клавиша F5) IIS не может сопоставить запрос с уже открытым сеансом. Он считает это подключение новым, инициирует следующий рабочий сеанс и забирает из пула еще одну лицензию.

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

Выясним, как правильно отредактировать этот файл. Откроем конфигурационный файл публикации default.vrd (обычно он находится в каталоге публикации базы на веб-сервере, например, C:\inetpub\wwwroot\НашаБаза\) и настроим параметры пула сеансов. Нам нужно добавить или отредактировать элементы в секции <point>:


<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/BaseName"
       ib="File="C:\1C_Bases\BaseName";">
    <ws>
        <point name="WebServices" alias="ws.1cws" enable="true"/>
    </ws>
    <httpServices publishByDefault="true"/>
    <pools>
        <pool size="10" 
              type="wait" 
              timeout="5" 
              reuseSessions="autouse" 
              sessionMaxAge="20" 
              sessionMaxIdleTime="10"/>
    </pools>
</point>

Рассмотрим подробнее, за что отвечают эти параметры пула:

reuseSessions="autouse" — предписывает системе автоматически и максимально быстро повторно использовать уже имеющиеся в пуле свободные сеансы вместо создания новых под каждый чих веб-клиента.
sessionMaxAge="20" — устанавливает максимальное время жизни неактивного сеанса в пуле в секундах. Ограничив его небольшим интервалом (например, 20–60 секунд), мы заставим систему оперативно уничтожать зависшие «мертвые» сеансы.
sessionMaxIdleTime="10" — время простоя сеанса перед тем, как он будет считаться кандидатом на удаление из пула.
size="10" — ограничивает максимальный размер пула сеансов.

Причина 2. Использование общего пула приложений IIS (DefaultAppPool)

По умолчанию при публикации баз 1С мастер автоматической публикации регистрирует все виртуальные каталоги в одном общем пуле приложений — DefaultAppPool. Если на сервере опубликовано несколько баз (например, одна УТ и три БП), рабочий процесс IIS w3wp.exe обрабатывает их совместно. При зависании лицензий в одной из баз администратору приходится перезапускать всю службу IIS, что мгновенно прерывает работу пользователей во всех остальных базах.

Давайте настроим изоляцию баз путем создания индивидуальных пулов приложений в IIS. Выполним следующие шаги:

Откроем Диспетчер служб IIS (Internet Information Services Manager).
В левом дереве выберем раздел Пулы приложений (Application Pools).
В панели действий справа выберем Добавить пул приложений (Add Application Pool). Назовем его именем нашей базы, например, 1C_Pool_UT11. Версию платформы .NET укажем как "Без управляемого кода" (No Managed Code).
Выберем созданный пул, перейдем в его Дополнительные параметры (Advanced Settings). Найдем параметр Загрузить профиль пользователя (Load User Profile) и установим его в значение False. Это существенно снизит вероятность блокировки временных файлов и папок процессами 1С под учетной записью пула.
Перейдем в раздел Сайты -> Default Web Site, найдем виртуальный каталог нашей опубликованной базы 1С.
В панели действий справа выберем Основные настройки (Basic Settings).
Нажмем кнопку Выбрать (Select) рядом с пулом приложений и назначим созданный нами ранее индивидуальный пул 1C_Pool_UT11.

Результат: Теперь каждая база работает в своем изолированном системном процессе. Если в базе УТ зависли лицензии, системному администратору больше не нужно перезагружать весь веб-сервер. Достаточно зайти в диспетчер IIS, выбрать пул 1C_Pool_UT11 и нажать кнопку Перезапуск (Recycle). Этот процесс занимает доли секунды, мгновенно убивает «зависшие» веб-сеансы именно этой информационной базы и освобождает лицензии, не затрагивая пользователей других баз.

Причина 3. Зависание терминальных RDP-сессий из-за процесса печати splwow64.exe

Эта проблема часто ставит в тупик даже опытных администраторов. Пользователь, работающий на сервере терминалов (RDS), корректно завершает работу в 1С (нажимает кнопку «Выход»), окно программы закрывается, но его сеанс на сервере терминалов переходит в состояние "Disconnected" (Отключен) вместо полноценного "Logoff" (Выход). Соответственно, терминальная сессия продолжает удерживать выделенную под этот сеанс программную лицензию 1С.

Выясним причину этого поведения. На 64-битных серверах Windows при печати документов из 32-битного клиента 1С операционная система запускает транслятор подсистемы печати — процесс splwow64.exe. По умолчанию Windows удерживает этот процесс в оперативной памяти до 20 минут после окончания печати, чтобы ускорить последующий вывод документов на принтер. До тех пор, пока процесс splwow64.exe активен в сессии пользователя, операционная система считает сессию занятой и не закрывает ее полностью.

Для решения этой проблемы настроим системный реестр Windows Server. Нам потребуется изменить два параметра в реестре сервера терминалов:

Откроем редактор реестра regedit от имени администратора.
Перейдем в ветку реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print
Создадим новый параметр типа DWORD (32 бита) с именем SplWOW64TimeOut и присвоим ему значение 1 (десятичное). Это сократит время ожидания закрытия процесса транслятора печати до 1 минуты после отправки последнего задания на принтер.
Перейдем в ветку реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\SysProcs
Создадим новый параметр типа DWORD (32 бита) с именем SPLWOW64.EXE и установим его значение равным 0. Это явно укажет системе, что данный процесс должен принудительно завершаться при выходе пользователя из терминальной сессии, не препятствуя разлогиниванию.

Для быстрого применения настроек вы можете импортировать готовый .reg-файл следующего содержания:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print]
"SplWOW64TimeOut"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\SysProcs]
"SPLWOW64.EXE"=dword:00000000

Причина 4. Неправильный тип активации комплекта лицензий 1С

Проанализируем архитектурную особенность платформы 1С. При покупке комплекта программных лицензий (например, на 5 или 10 рабочих мест) администратору выдаются пин-коды двух видов: набор однопользовательских пин-кодов и один многопользовательский пин-код. Очень часто совершают ошибку, активируя лицензии на сервере как 10 отдельных однопользовательских лицензий.

При использовании файловой базы данных, опубликованной на веб-сервере (IIS или Apache), модули расширения веб-сервера 1С не умеют корректно подхватывать и распределять одиночные лицензии, активированные в сессиях локальных пользователей сервера. Веб-сервер работает от имени системной учетной записи IIS (например, IIS_IUSRS) и не имеет доступа к лицензиям, привязанным к профилям пользователей.

Решение: При публикации файловой базы на IIS комплект лицензий необходимо активировать строго как одну многопользовательскую лицензию на самом компьютере веб-сервера. При этом файл лицензии с расширением .lic должен быть размещен в общедоступном для всех пользователей каталоге, например: C:\ProgramData\1C\licenses\. В этом случае модуль расширения веб-сервера сможет централизованно и монопольно забирать свободные лицензии из единого многопользовательского файла и выдавать их подключающимся веб-клиентам.

Причина 5. Современная альтернатива — использование автономного сервера 1С

Если в вашей организации используется современная версия платформы «1С:Предприятие» (начиная с релиза 8.3.20 и выше), рассмотрите возможность отказа от прямой публикации файловой базы через IIS/Apache в пользу использования встроенного Автономного сервера 1С (исполняемый файл ibsrv.exe).

Автономный сервер — это облегченная версия полноценного сервера приложений 1С, предназначенная специально для файловых баз. Он берет на себя всю работу по управлению сеансами, базами данных и выдачей программных лицензий. При работе через автономный сервер:

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

Причина 6. Настройка параметров спящего режима в конфигурации 1С

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

Запустим программу «1С:Предприятие» под учетной записью с административными правами.
Перейдем в раздел НСИ и администрирование -> Обслуживание -> Активные пользователи (или воспользуемся поиском функций, введя «Параметры работы пользователей»).
Установим флаг Выходить из программы при бездействии.
Зададим разумные временные рамки:
- Время бездействия (минут): например, 20 минут. Если пользователь отойдет от компьютера, система переведет его сеанс в "спящий" режим.
- Время завершения спящего сеанса (секунд): укажем 120 секунд. По истечении этого времени сеанс будет окончательно удален из базы данных, а занимаемая им программная лицензия гарантированно вернется в пул свободных лицензий.

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