Публикация информационной базы 1С на веб-сервере Internet Information Services (IIS) — стандартная процедура для обеспечения доступа через веб-клиент или мобильные приложения. Однако на практике системные администраторы часто сталкиваются с ошибками типа 404 Not Found или 500.21 Internal Server Error. Эти проблемы обычно связаны с некорректной конфигурацией компонентов Windows, несоответствием разрядности (32/64 бит) или недостатком прав доступа. В этой статье мы подробно разберем, как привести сервер в рабочее состояние.
Первоочередная причина ошибки 500.21 (связанной с поврежденным модулем IsapiModule) заключается в том, что в системе не установлены расширения, необходимые для работы обработчика 1С. По умолчанию при установке IIS многие из них выключены. Проанализируем список обязательных компонентов.
Нам необходимо зайти в «Включение или отключение компонентов Windows» (или «Роли и компоненты» в серверных ОС) и убедиться, что отмечены следующие пункты в разделе Службы IIS -> Службы Интернета -> Компоненты разработки приложений:
wsisapi.dll.Как показывает практика, отсутствие ASP модулей часто приводит к зависанию публикации или ошибкам сервера даже при правильной настройке обработчиков. После установки этих компонентов рекомендуется перезапустить службу IIS.
Если компоненты установлены, но база все равно выдает ошибку 500, проверим «Сопоставление обработчиков» (Handler Mappings). Рассмотрим, как правильно зарегистрировать 1С в структуре IIS. Выясним причину, по которой сервер может не видеть модуль 1С.
В Диспетчере служб IIS на уровне конкретного приложения или всего сервера нужно найти пункт «Сопоставление обработчиков». Здесь должен присутствовать обработчик для 1С. Если его нет или он настроен неверно, выполним следующие действия:
* (или конкретное расширение, если требуется тонкая настройка).wsisapi.dll.Важный нюанс: путь к исполняемому файлу зависит от разрядности установленной платформы 1С. Рассмотрим типичные пути:
C:\Program Files\1cv8\номер_версии\bin\wsisapi.dllC:\Program Files (x86)\1cv8\номер_версии\bin\wsisapi.dllОдной из самых коварных ошибок является несоответствие разрядности wsisapi.dll и настроек Пула приложений (Application Pool). Разберем ситуацию: вы установили 64-битную платформу, указали верный путь к DLL, но сервер выдает ошибку 500.
Проанализируем настройки пула:
DefaultAppPool).Здесь кроется решение: если вы используете 64-битную версию платформы 1С, этот параметр должен быть установлен в False. Если же у вас 32-битная 1С, установите значение True. Попытка запустить 64-битную библиотеку в пуле, где разрешены 32-битные приложения, всегда приводит к сбою модуля ISAPI.
Ошибка 401 (Access Denied) или даже 404 (если сервер не может прочитать конфигурационный файл web.config) часто вызвана правами доступа. Рассмотрим, каким учетным записям нужны права.
В современных версиях IIS за работу пула отвечает виртуальная учетная запись. Мы должны предоставить права «Чтение и выполнение» (а для каталога базы в файловом варианте — «Полный доступ») следующим пользователям:
IUSR (встроенная учетная запись для анонимного доступа).IIS_IUSRS (группа пользователей IIS).IIS AppPool\ИмяВашегоПула (например, IIS AppPool\DefaultAppPool). Это критически важный момент, про который часто забывают.Права должны быть даны не только на каталог, где лежит опубликованный default.vrd, но и на папку с исполняемыми файлами 1С (каталог bin), чтобы IIS мог загрузить wsisapi.dll.
Иногда настройки на уровне сайта выполнены верно, но выполнение расширения запрещено на уровне всего сервера. Посмотрим на этот параметр подробнее.
В корневом узле дерева подключений Диспетчера IIS найдем пункт «Ограничения ISAPI и CGI». Проверим, есть ли там запись, указывающая на вашу wsisapi.dll. Если записи нет, ее нужно добавить вручную, указав путь к DLL и установив галочку «Разрешить выполнение расширения». Без этого глобального разрешения IIS будет блокировать любые попытки запуска модуля 1С.
Если после публикации база начинает загружаться, но вы видите ошибку TypeError: cannot declare global binding 'Ya', не спешите искать проблему в коде 1С. Эта ошибка часто вызвана внешним вмешательством в работу браузера.
Проанализируем ситуацию: это происходит из-за расширений браузера (например, от «Яндекса») или встроенных сервисов метрики в браузерах на базе Chromium. Скрипт расширения пытается внедрить свою переменную в глобальную область видимости, что конфликтует с защищенным контекстом веб-клиента 1С. Решение: попробуйте открыть базу в режиме «Инкогнито» или временно отключите все расширения браузера.
Иногда публикация «слетает» из-за ошибок в файле default.vrd. Это XML-файл, который 1С создает в каталоге публикации. Рассмотрим пример типичного файла:
<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="/MyBase"
ib="File="C:\Bases\MyBase";">
<ws>
<point name="WebServiceName"
alias="ws1.1cws"
enable="true"/>
</ws>
</point>
Убедитесь, что в этом файле пути к базе данных указаны верно, а имена серверов (в случае клиент-серверного варианта) соответствуют их реальному написанию в консоли администрирования 1С. Помните, что IIS может быть чувствителен к регистру символов в некоторых настройках.
Подведем итог наших действий. Для успешной публикации мы должны:
wsisapi.dll нужной разрядности.bin 1С и каталог с базой.Выполнив эти шаги последовательно, мы устраним основные причины ошибок 404 и 500, обеспечив стабильную работу веб-клиента 1С на сервере IIS.