Переход на новую версию платформы 1С:Предприятие 8.3: от дистрибутива до рабочей базы

Обновить платформу 1С — это поставить новую версию «движка» 1С:Предприятие 8.3 (например, перейти с 8.3.24 на 8.3.25), а не обновить конфигурацию . Новая версия устанавливается рядом со старой, сами базы при этом не трогаются. Для файловой базы достаточно запустить из дистрибутива setup.exe и пройти установку; для клиент-серверной нужно остановить службу сервера, обновить серверные компоненты и запустить службу заново.

Платформа и конфигурация (Бухгалтерия, ЗУП, Управление торговлей) обновляются по отдельности и разными способами. На одном компьютере спокойно уживаются несколько версий платформы — старую обычно не удаляют, пока не убедились, что на новой всё работает. Ниже — как выполнить обновление для файлового варианта, для сервера и для тонкого клиента , как переключаться между версиями и что проверить в конце.

Платформа и конфигурация: что именно вы обновляете

Платформа — это технологическое ядро: исполняемые файлы 1cv8.exe, сервер, веб-сервисы, механизм лицензирования. Конфигурация — прикладное решение, которое работает поверх платформы. Когда в окне «О программе» видите две строки версий, верхняя (вида 8.3.xx.xxxx) — это платформа.

Обновлять платформу приходится в нескольких случаях:

• 📦 новый релиз конфигурации требует версию платформы не ниже определённого номера — иначе база просто не откроется;
• 🛡️ в свежих версиях закрывают уязвимости и ошибки, влияющие на стабильность;
• ⚙️ появляются новые возможности интерфейса и механизмы обмена, нужные для свежих форм отчётности;
• 🧩 требование по совместимости выставляет сопровождающий партнёр или собственная ИТ-служба.

Минимально необходимую версию платформы задаёт сама конфигурация — её видно при попытке запуска на устаревшей платформе в тексте ошибки, а также в описании релиза конфигурации, которое публикует её разработчик. Сравнивайте версии по номеру однозначно: подходит любая, у которой номер не ниже требуемого. Формулировки «старше» и «младше» здесь путают — ориентируйтесь только на числовой номер вида 8.3.25.xxxx.

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

Что проверить и сохранить перед обновлением

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

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

Разрядность менять по ходу обновления не стоит: если сервер работал в 64-битном режиме, оставляйте 64-битный. Смешение 32- и 64-битных компонентов — частая причина того, что служба после обновления не стартует.

Какой способ обновления выбрать

Способ зависит от того, как у вас развёрнута база. Для одиночного рабочего места это ручная установка дистрибутива . Для сети на общей папке — та же ручная установка на каждом компьютере либо настроенное автообновление. Для клиент-серверного варианта платформу обновляют на сервере, а тонкие клиенты подтягивают нужную версию сами.

Установка новой версии платформы вручную

Ручная установка подходит для файловой базы и для клиентских рабочих мест. Порядок одинаковый:

1. Распакуйте скачанный дистрибутив платформы в отдельную папку.
2. Запустите setup.exe от имени администратора.
3. В мастере установки оставьте компонент «1С:Предприятие» (тонкий и толстый клиент); при необходимости отметьте «Администрирование сервера» или «Модули расширения веб-сервера».
4. Пройдите шаги мастера до конца. Установщик разместит новую версию в каталоге вида C:\Program Files\1cv8\<номер версии>\bin — рядом со старой, не затирая её.
5. Запустите базу через ярлык «1С:Предприятие» или 1cestart.exe. Если список версий настроен правильно, запустится новая платформа.

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

Обновление платформы на сервере и в сетевых базах

На клиент-серверном варианте порядок другой: сначала сервер, потом клиенты. Серверную часть обновляют с остановкой службы агента сервера.

⚠️ Остановка службы сервера 1С завершает все активные сеансы пользователей и прерывает фоновые и регламентные задания. Выполняйте обновление только в согласованное окно, когда в базе никто не работает .

Общий порядок на сервере:

1. Убедитесь, что пользователи вышли (список сеансов видно в консоли администрирования кластера или командой rac session list).
2. Остановите службу «Агент сервера 1С:Предприятия» (ragent) — через оснастку «Службы» Windows либо net stop.
3. Установите серверный дистрибутив новой версии (setup.exe, компонент «Сервер 1С:Предприятия»).
4. Перерегистрируйте службу на новую версию. В мастере установки серверного дистрибутива есть шаг установки/изменения службы сервера — он прописывает путь к исполняемым файлам новой версии. Если делаете вручную, службу создают заново с путём к ragent.exe из нового каталога bin.
5. Запустите службу и проверьте, что кластер поднялся (rac cluster list возвращает кластер, консоль администрирования подключается).

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

Для терминального доступа и RemoteApp платформу обновляют один раз на терминальном сервере — у всех пользователей сразу появляется новая версия. Веб-клиент требует обновления модулей расширения веб-сервера (setup.exe, соответствующий компонент) и перезапуска веб-сервера.

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

На Linux-сервере порядок тот же по смыслу, но компоненты ставятся из пакетов (deb/rpm) соответствующего дистрибутива, а служба сервера перезапускается средствами системы инициализации. Разрядность и здесь менять не нужно — ставьте пакеты той же архитектуры.

Как переключаться между версиями платформы

Раз на компьютере лежат несколько версий, важно понимать, какая из них запустится. Выбором управляет файл конфигурации запуска 1CEStart.cfg и список информационных баз. По умолчанию стартер 1cestart.exe берёт самую свежую установленную версию.

Жёстко закрепить версию за базой можно двумя способами:

• 🔒 указать требуемую версию в свойствах базы в окне запуска — тогда база будет стартовать именно на ней, даже если установлены версии новее;
• 🗂️ прописать версию в параметрах 1CEStart.cfg для всех баз сразу — это удобно, когда на парке машин нужно единообразие.

Такой контроль спасает в типичной ситуации: поставили новую платформу «на пробу», а она оказалась несовместима с внешней обработкой или драйвером оборудования. Пока старая версия не удалена, достаточно вернуть требуемую версию — и база снова запускается на проверенной платформе.

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

Если после обновления что-то не работает

Большинство сбоев после обновления платформы — это рассогласование версий клиента и сервера или не перезапущенная служба. Разберём частое:

Отдельно про лицензии: обновление платформы в пределах версии 8.3 обычно не требует повторной активации. Аппаратный ключ HASP и ранее активированные программные лицензии продолжают работать. Если после обновления платформа просит лицензию, проверьте, что служба сервера лицензирования запущена и ключ доступен, — файлы лицензий при установке новой версии не удаляются.

Как убедиться, что обновление прошло успешно

Проверка занимает пару минут и защищает от сюрприза в разгар рабочего дня:

1. Откройте базу и в меню Справка → О программе сверьте номер версии платформы — он должен совпасть с установленной.
2. Зайдите в несколько рабочих разделов, откройте пару отчётов и проведите тестовый документ в копии базы — убедитесь, что формы открываются без ошибок.
3. Для клиент-серверной базы проверьте, что консоль администрирования подключается к кластеру, а тонкий клиент подключился на новой версии.
4. Откройте конфигурацию в конфигураторе — если платформа несовместима с текущим релизом конфигурации, это проявится сразу.
5. Проверьте работу торгового и фискального оборудования, если оно подключено: драйверы иногда чувствительны к смене платформы.

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

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