Как правильно обновить платформу 1С на сервере и клиентских компьютерах при работе через веб-сервер

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

В этой статье мы подробно разберем ручные и автоматизированные методы обновления платформы 1С, рассмотрим особенности совместной работы разных версий и проанализируем критические риски, связанные с размером файловых баз данных.

Метод 1. Последовательное ручное обновление платформы

Если пользователей немного (до 5–10 человек) и у администратора есть прямой доступ к их компьютерам (например, через TeamViewer, AnyDesk или по локальной сети), можно применить классическую последовательную схему обновления. Разберем этот процесс по шагам.

1. Создание резервной копии. Перед началом любых манипуляций с платформой и базой данных в обязательном порядке создаем резервную копию файла базы данных 1Cv8.1CD. Это критически важное правило, которое убережет данные в случае непредвиденных сбоев.
2. Завершение сеансов пользователей. Просим всех пользователей выйти из программы. Убеждаемся, что на веб-сервере нет активных сеансов к нашей базе данных.
3. Обновление платформы на сервере. Устанавливаем новую версию технологической платформы 1С на сервере, где физически расположена база данных.
4. Перепубликация базы данных. Это важнейший шаг при использовании веб-сервера. Запускаем Конфигуратор 1С новой версии от имени администратора операционной системы. Переходим в меню Администрирование — Публикация на веб-сервере. Нажимаем кнопку Опубликовать. Это необходимо для того, чтобы модули веб-сервера (расширения IIS или Apache) обновились и начали использовать библиотеки новой версии платформы.
5. Перезапуск веб-сервера. Выполняем перезапуск службы веб-сервера (например, службы World Wide Web Publishing Service для IIS или службы Apache).
6. Обновление клиентов. Устанавливаем ту же самую версию платформы на компьютерах пользователей. После этого пользователи могут запускать 1С и продолжать работу.

Метод 2. Постепенное обновление клиентов (подготовка за один день)

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

Работать с одной базой данных с разных версий платформы напрямую нельзя — система выдаст ошибку о несоответствии версий клиента и сервера. Однако мы можем подготовить клиентские компьютеры заранее. Рассмотрим эту схему:

1. Накануне планируемого обновления подключаемся к компьютерам пользователей и устанавливаем новую версию платформы 1С:Предприятие. При этом старую версию платформы удалять ни в коем случае нельзя!
2. В настройках запуска базы данных на компьютерах пользователей временно жестко прописываем использование старой версии платформы. Для этого в окне запуска 1С выбираем нужную базу, нажимаем Изменить, переходим на последнюю вкладку настроек и в поле Версия платформы указываем конкретный старый релиз (например, 8.3.10.2667).
3. В день обновления администратор проводит работы на сервере (обновляет платформу на сервере, обновляет публикацию на веб-сервере и перезапускает службу).
4. После этого пользователям достаточно лишь изменить настройки запуска: либо удалить жесткое указание версии (чтобы система автоматически выбрала последнюю установленную версию), либо прописать новую версию (например, 8.3.12.1567).

Для удобства можно создать в списке баз два подключения к одной и той же информационной базе с разными именами — например, "Салон (Старая платформа)" и "Салон (Новая платформа)", настроив в каждом подключении соответствующие параметры запуска. В момент перехода пользователям останется просто запустить базу по новому ярлыку.

Метод 3. Автоматическое обновление тонкого клиента через веб-сервер

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

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

Выполним настройку по шагам:

1. Скачиваем с портала 1С дистрибутив тонкого клиента нужной версии для операционных систем пользователей (например, тонкий клиент для Windows 32-бит и 64-бит).
2. Запаковываем файлы дистрибутива в стандартный архив .zip. Важно: внутри архива не должно быть лишних вложенных папок, файлы установки (setup.exe, 1CEnterprise8.msi и др.) должны находиться в корне архива.
3. Размещаем этот архив в публичной папке на веб-сервере. Например, создаем в каталоге веб-сервера папку distr и копируем архив туда.
4. Настройка MIME-типов. В настройках веб-сервера (IIS или Apache) обязательно проверяем наличие MIME-типа для расширения файла .zip. Он должен быть определен как application/zip. Без этого веб-сервер не разрешит скачивание архива клиентом.
5. Публикация дистрибутива в Конфигураторе. Открываем Конфигуратор нашей базы на сервере. Переходим в меню публикации на веб-сервере. На вкладке Дополнительные устанавливаем флаг Публиковать дистрибутив тонкого клиента и указываем URL-адрес к нашему ZIP-архиву на веб-сервере.

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

Метод 4. Настройка автообновления по локальной сети через 1CEStart.cfg

Если удаленные офисы подключены к центральному серверу через VPN или работают в локальной сети, можно настроить автоматическое обновление платформы с помощью общего сетевого ресурса. Разберем этот вариант подробнее.

Для реализации этого метода нам потребуется настроить общий конфигурационный файл запуска 1CEStart.cfg, который считывается программой запуска (стартером) при каждом обращении к списку баз.

Выполним следующие действия:

1. Создаем на сервере общую сетевую папку (например, \\Server-1C\1C_Distr) и предоставляем пользователям права на чтение файлов в этом каталоге.
2. Помещаем в эту папку распакованные дистрибутивы новых версий платформы 1С.
3. На компьютерах пользователей находим конфигурационный файл 1CEStart.cfg (обычно он располагается по пути %AppData%\1C\1CEStart\1CEStart.cfg).
4. Редактируем данный файл, прописывая пути к общему сетевому каталогу. Пример конфигурации выглядит следующим образом:

CommonCfgLocation=\\Server-1C\1C_Distr\1CEStart.cfg
DistributiveLocation=\\Server-1C\1C_Distr
AppAutoInstallLastVersion=1

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

Критический анализ рисков файлового режима

В процессе администрирования баз данных 1С важно вовремя заметить технические ограничения инфраструктуры. Рассмотрим ситуацию, когда размер файловой базы данных достигает 4.51 ГБ.

Многие специалисты ошибочно полагают, что если файловая база работает без видимых зависаний, то переходить на клиент-серверный вариант (SQL) нет необходимости. Это опасное заблуждение. Проанализируем причину:

• Файловая база данных представляет собой единый файл 1Cv8.1CD, состоящий из внутренних таблиц.
• В платформе 1С существует строгое ограничение: размер **одной внутренней таблицы** в файловой базе данных по умолчанию не может превышать 4 ГБ.
• Если общий размер базы составляет 4.51 ГБ, это означает, что некоторые таблицы (например, таблицы итогов регистров накопления или таблицы версий объектов) уже вплотную приблизились к критическому порогу.
• Как только размер любой из внутренних таблиц превысит лимит, база заблокируется с критической ошибкой СУБД, и работа всей компании будет полностью парализована.

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

1. Использование лицензии "1С:Сервер МИНИ". Это официальное и доступное решение от фирмы 1С, которое рассчитано на подключение до 5 пользователей. Стоимость такой лицензии в разы ниже стандартной серверной лицензии.
2. Бесплатная СУБД PostgreSQL. Совместно с сервером 1С можно использовать бесплатную базу данных PostgreSQL, которая отлично оптимизирована для работы с платформой 1С и полностью снимает все ограничения на объемы данных.
3. Переход в облачный сервис 1С:Фреш. Это идеальный вариант для небольших компаний с распределенной структурой. Вся база данных переносится в облако 1С. При этом администрирование, обновление платформы, создание архивных копий и масштабирование СУБД полностью ложатся на плечи провайдера, освобождая время системного администратора.

Также важно обратить внимание на саму версию платформы, планируемую к установке. Переход на устаревшие ветки (такие как 8.3.12) несет в себе риски безопасности и несовместимости со сторонними государственными сервисами (ЕГАИС, Честный Знак, взаимодействие с банками по современным протоколам шифрования TLS). Рекомендуется выбирать актуальные стабильные релизы технологической платформы из поддерживаемых веток (например, 8.3.22 или 8.3.24), предварительно ознакомившись с требованиями вашей конфигурации.