Как обновить модули расширения веб-сервера 1С

Модули расширения веб-сервера 1С — это компоненты, которые связывают IIS или Apache с платформой «1С:Предприятие»: они принимают HTTP-запросы, передают их рабочим процессам сервера 1С или файловой базе и возвращают ответ клиенту. Каждая версия платформы поставляет свои версии этих модулей, и после обновления платформы старые бинарные файлы на веб-сервере остаются прежними, пока их не заменить вручную.

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

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

Что именно нужно обновлять и когда

Под модулями расширения веб-сервера понимаются бинарные файлы, которые поставляются в составе дистрибутива платформы: для IIS это ISAPI-модуль wsisapi.dll, для Apache — библиотека wsap24.dll (Windows) или mod_1cws.so (Linux). Именно эти файлы загружаются веб-сервером и обращаются к платформе 1С.

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

Важно понимать, что модули живут на машине с веб-сервером, а не на сервере 1С. Если веб-сервер и кластер 1С разнесены на разные компьютеры, обновлять компоненты нужно именно там, где работает IIS или Apache, — иначе несовпадение версий сохранится.

Подготовка: резервная копия и проверка версий

Перед любыми действиями зафиксируйте текущее состояние. Сохраните каталог публикации (там лежат default.vrd и, возможно, пользовательские настройки), конфигурационные файлы веб-сервера — httpd.conf для Apache или настройки сайта и пулов приложений для IIS. Это позволит быстро откатиться, если новая версия модуля окажется несовместимой с окружением.

Затем сверьте версии. Версию платформы сервера 1С видно в консоли кластера, версию модуля на веб-сервере — в свойствах файла wsisapi.dll или wsap24.dll в каталоге публикации. Если они различаются — обновление необходимо. Заодно уточните разрядность: 64-разрядный веб-сервер требует 64-разрядных модулей, смешивание разрядности — частая причина сбоев.

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

Шаг 1. Установка компонентов новой версии платформы на веб-сервер

Запустите установщик платформы 1С той же версии, что работает на сервере 1С, на компьютере с веб-сервером. В списке компонентов отметьте «Модули расширения веб-сервера» (в новых версиях установщика пункт может называться «Расширение для веб-сервера»). Остальные компоненты — сервер, толстый клиент — на веб-сервере не обязательны, но установщик сам не удалит уже стоящее.

После установки новые файлы модулей появятся в каталоге bin соответствующей версии платформы, например C:\Program Files\1cv8\<версия>\bin\. Старые версии платформы при этом не удаляются — это нормально и даже полезно для отката.

Убедитесь, что установленная разрядность совпадает с разрядностью веб-сервера: для 64-разрядного IIS с включённым 64-битным режимом пула приложений нужен 64-разрядный модуль. Проверить режим пула можно в диспетчере IIS, в дополнительных параметрах пула приложений (параметр «Разрешить 32-разрядные приложения»).

Шаг 2. Перепубликация базы утилитой webinst

Самый надёжный способ обновить модули — перепубликовать базу: при публикации платформа копирует актуальные файлы модуля в каталог публикации и прописывает корректные настройки. Основной инструмент — утилита командной строки webinst, которая лежит в каталоге bin нужной версии платформы.

Для Apache на Windows команда публикации выглядит примерно так (путь к утилите и имена замените на свои):

"C:\Program Files\1cv8\8.3.24.1467\bin\webinst.exe" -publish -apache24 -wsdir trade -dir "C:\www\trade" -connstr "Srvr=srv1c;Ref=trade;" -confpath "C:\Apache24\conf\httpd.conf"

Ключ -publish выполняет публикацию, -apache24 указывает тип веб-сервера, -wsdir — имя виртуального каталога, -dir — физический каталог публикации, -connstr — строка соединения с базой, -confpath — путь к конфигурации Apache. Для IIS используется ключ -iis вместо -apache24, а -confpath не нужен.

После успешной публикации в каталоге -dir появится свежий default.vrd, а модуль веб-сервера будет зарегистрирован заново. Если публикация завершилась ошибкой доступа — запустите командную строку от имени администратора и проверьте права на каталог публикации и на конфигурационный файл Apache.

1. 1
   Сохраните каталог публикации и конфигурацию веб-сервера
2. 2
   Установите компонент «Модули расширения веб-сервера» новой версии платформы на машину с веб-сервером
3. 3
   Перепубликуйте базу через webinst или конфигуратор
4. 4
   Перезапустите веб-сервер (iisreset или restart Apache)
5. 5
   Проверьте версию модуля в каталоге публикации и работу веб-клиента

Шаг 3. Альтернатива: публикация через конфигуратор

Если командная строка неудобна, перепубликацию можно выполнить из конфигуратора: меню «Администрирование» → «Публикация на веб-сервере». В диалоге укажите имя публикации, тип веб-сервера (IIS или Apache), каталог и при необходимости отметьте публикуемые сервисы — веб-клиент, HTTP-сервисы, веб-сервисы.

Конфигуратор при публикации использует ту же механику, что и webinst, и обновляет файлы модуля в каталоге публикации. Ограничение способа: конфигуратор должен быть запущен на машине с веб-сервером (или публикация должна выполняться локально), а пользователь — иметь административные права на веб-сервер. Для удалённого веб-сервера удобнее webinst.

Ручная замена файлов модуля — когда без перепубликации не обойтись

Иногда администраторы просто копируют новый wsisapi.dll или wsap24.dll поверх старого в каталоге публикации. Такой приём работает, только если структура публикации не менялась и настройки в default.vrd остались актуальными. Однако при смене версии платформы перепубликация надёжнее: она заодно обновляет регистрацию модуля в веб-сервере. Ручную замену используйте как временную меру, а не как стандартную практику.

Шаг 4. Перезапуск веб-сервера и проверка результата

Веб-сервер держит загруженный модуль в памяти, поэтому после замены файлов его нужно перезапустить. Для IIS выполните в командной строке от администратора iisreset или перезапустите конкретный пул приложений — это мягче и не затрагивает другие сайты. Для Apache — перезапустите службу через services.msc или командой httpd -k restart.

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

Если вместо клиента приходит ошибка — смотрите журналы. Для IIS это журнал событий Windows и логи сайта, для Apache — error.log. Типичные записи: «не удаётся загрузить модуль» (разрядность или отсутствие зависимых библиотек), «отказано в доступе» (права на каталог), ошибки соединения с сервером 1С (неверная строка соединения в default.vrd).

Типичные ошибки при обновлении модулей

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

Отдельно отметим ситуацию с несколькими публикациями на одном веб-сервере. Если базы опубликованы под разные версии платформы, обновлять модули нужно для каждой публикации отдельно и только той версией, под которой работает конкретная база. Одна команда webinst обновляет одну публикацию.

Ограничения и когда нужна помощь специалиста

Самостоятельное обновление оправдано, когда есть административный доступ к веб-серверу, резервная копия публикаций и возможность кратковременного простоя. Если веб-сервер обслуживает внешние сервисы для клиентов, работает в связке с балансировщиком или на нём настроена нестандартная аутентификация (например, через прокси или SSO), сначала протестируйте обновление на копии окружения.

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

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