Обновление платформы «1С:Предприятие» на сервере — стандартная процедура для системного администратора. Однако часто после установки новой версии платформы и удаления старой пользователи сталкиваются с неприятной проблемой. При попытке запустить информационную базу система выдает критическую ошибку: «Несоответствие версий клиента и сервера 1С:Предприятия. Различаются версии клиента и сервера». При этом кажется, что все действия выполнены верно: старая платформа деинсталлирована, новая успешно установлена, но система продолжает «цепляться» за предыдущий релиз.
В этой статье мы подробно разберем, почему возникает эта ошибка, где именно операционная система сохраняет пути к старой платформе и как по шагам устранить эту проблему на сервере и клиентских машинах.
Основная архитектурная особенность клиент-серверной версии «1С:Предприятия» заключается в том, что клиентское приложение и серверная часть (кластер серверов) должны иметь абсолютно идентичный номер релиза платформы. Разница даже в последней цифре сборки (например, клиент запускает 8.3.25.1374, а на сервере крутится 8.3.25.1520) гарантированно приведет к аварийному завершению работы с сообщением о несоответствии версий.
Когда вы обновляете платформу на сервере, штатный деинсталлятор Windows не всегда корректно перенастраивает системные службы, веб-публикации и библиотеки взаимодействия. В результате серверная часть продолжает работать на старом исполняемом файле, либо клиентские компьютеры пытаются использовать старый локальный кэш. Рассмотрим подробные сценарии решения этой проблемы.
Это наиболее частая причина сбоя. При удалении старого релиза через стандартную утилиту «Установка и удаление программ» сама служба 1C:Enterprise 8.3 Server Agent остается зарегистрированной в операционной системе, но продолжает ссылаться на исполняемый файл ragent.exe, находящийся в каталоге старой версии платформы. Если этот каталог был физически удален, служба просто не запустится, а если файлы частично остались, она запустит серверную часть старого релиза.
Проанализируем ситуацию и исправим путь к исполняемому файлу службы Агента сервера через реестр Windows по шагам:
regedit и нажмите Enter для запуска Редактора реестра с правами администратора.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (x86-64)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent
"C:\Program Files\1cv8\8.3.25.1374\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -appid 1cv8
8.3.25.1374) на точный номер новой установленной платформы (например, 8.3.25.1520).
services.msc в меню Выполнить).Если вы предпочитаете не работать с реестром напрямую, вы можете перерегистрировать службу Агента сервера через командную строку. Для этого запустите консоль cmd от имени администратора и выполните следующие команды:
cd /d "C:\Program Files\1cv8\СТАРАЯ_ВЕРСИЯ\bin"
ragent.exe -rmsrvc
cd /d "C:\Program Files\1cv8\НОВАЯ_ВЕРСИЯ\bin"
ragent.exe -instsrvc -usr ".\USR1CV8" -pwd "ПарольПользователя1С" -regport 1541 -port 1540 -appid 1cv8
Первая команда удаляет старую службу из системы, а вторая — регистрирует новую службу из каталога свежеустановленной платформы с привязкой к системному пользователю 1С.
Если ваши пользователи работают с информационными базами через веб-клиент (браузер) или тонкий клиент по протоколам HTTP/HTTPS, то причиной удержания старой версии платформы является веб-сервер. В файлах конфигурации веб-сервера жестко прописывается путь к библиотекам расширения веб-сервисов 1С.
Выясним, как обновить эти параметры для популярных веб-серверов.
При использовании Apache все настройки модулей хранятся в конфигурационном файле httpd.conf. Выполните следующие шаги для исправления путей:
C:\Program Files\Apache Software Foundation\Apache2.4\conf\).httpd.conf.LoadModule _1cws_module "C:/Program Files/1cv8/8.3.25.1374/bin/wsap24.dll"
wsap24.dll на новый актуальный релиз.Для IIS процедуру обновления проще всего выполнить через повторную публикацию базы из конфигуратора новой версии платформы:
Часто ошибка несоответствия версий проявляется не при обычном входе пользователя, а при попытке программной интеграции (например, при обмене данными между двумя базами 1С, когда одна база обращается к другой через COM-соединение). В этом случае внешнее приложение обращается к зарегистрированной в операционной системе динамической библиотеке comcntr.dll, которая осталась от старой платформы.
Чтобы зарегистрировать библиотеку нового релиза платформы в системе Windows, выполните следующие действия:
cmd) обязательно от имени Администратора.
regsvr32 /u "C:\Program Files\1cv8\СТАРАЯ_ВЕРСИЯ\bin\comcntr.dll"
regsvr32 "C:\Program Files\1cv8\НОВАЯ_ВЕРСИЯ\bin\comcntr.dll"
Рассмотрим ситуацию с клиентской стороны. Бывает так, что администратор обновил платформу на сервере и установил её на клиентских машинах, но у конкретного пользователя все равно возникает ошибка несоответствия версий. Выясним, почему это происходит.
Очень часто пользователи создают ярлыки запуска 1С не на общую программу-стартер, а напрямую на исполняемый файл конкретной старой версии. Например, ярлык ссылается на:
C:\Program Files\1cv8\8.3.25.1374\bin\1cv8c.exe
Когда вы удаляете старый релиз платформы, этот ярлык либо перестает работать вовсе, либо запускает остаточные исполняемые файлы, которые не обновились. Правильное решение: перенаправить все ярлыки пользователей на общий загрузчик 1С, который самостоятельно определяет последнюю установленную версию платформы на компьютере и запускает именно её:
"C:\Program Files\1cv8\common\1cv8estart.exe"
Также проверьте настройки конкретной информационной базы в списке баз пользователя:
8.3.25.1374), очистите это поле или укажите значение 8.3. При пустом поле система автоматически выберет самый свежий установленный релиз платформы из ветки 8.3.В процессе многолетней эксплуатации сервера 1С на нем могли накапливаться остатки старых версий. Распространенный сценарий: ранее на сервере использовался 32-битный сервер 1С, а затем его обновили на 64-битный. При этом в службах Windows могут остаться зарегистрированными обе службы Агента сервера 1С.
При перезапуске сервера операционная система может запустить старую 32-битную службу быстрее, заблокировав стандартные сетевые порты 1540 и 1541. В результате новая служба 64-битного сервера не может инициализировать сетевые сокеты, а пользователи при подключении попадают на старый 32-битный рабочий процесс, получая ошибку несоответствия версий.
Проанализируем список служб на сервере:
services.msc.x86-64, а другую без нее), отключите неиспользуемую архитектуру. Установите для старой службы тип запуска Отключена.Чтобы раз и навсегда избавить себя от необходимости вручную обновлять платформу на каждом клиентском компьютере и предотвратить появление ошибок несоответствия версий в будущем, настройте встроенный механизм автообновления тонких клиентов.
Разберем, как это реализовать:
\\Server1C\Distr1C).conf.cfg (обычно он находится по пути C:\Program Files\1cv8\conf\).
PublishDistributiveLocationWindows32=\\Server1C\Distr1C
PublishDistributiveLocationWindows64=\\Server1C\Distr1C
Используя приведенные пошаговые инструкции, вы сможете быстро локализовать источник проблемы и восстановить бесперебойную работу пользователей в информационной базе 1С после планового обновления платформы.