Обновление платформы 1С:Предприятие — это ответственный процесс, который при неправильном подходе может привести к простою компании. Особенно это касается клиент-серверных вариантов работы, где задействованы службы Windows (или Linux) и СУБД. В данной статье мы подробно разберем, как перейти на версию 8.3.10.2667, проанализируем последовательность действий и выясним, какие скрытые угрозы могут поджидать системного администратора.
Прежде чем приступать к установке новых файлов, нам необходимо подготовить информационную базу. Рассмотрим этот этап пошагово. Нельзя просто запустить инсталлятор, пока в системе находятся люди или работают регламентные задания.
Во-первых, проанализируем текущую активность. Зайдем в Консоль администрирования кластера серверов 1С. Здесь нам нужно убедиться, что все активные сеансы завершены. Если пользователи игнорируют просьбы выйти из программы, мы можем завершить их принудительно через консоль. Однако более правильным методом будет установка блокировки соединений.
Разберем, как это сделать через «Конфигуратор» или «Администрирование» в режиме «Предприятие»:
123), который позволит нам самим зайти в базу под новой платформой для проверки, пока остальные пользователи еще заблокированы.Это действие гарантирует, что в процессе копирования файлов или обновления структуры конфигурации никто не создаст новый сеанс, что могло бы привести к повреждению данных или ошибке совместного доступа к файлам.
Критически важный момент, который часто упускают новички: сервер 1С необходимо остановить перед установкой. Платформа 1С работает как системная служба, и многие исполняемые файлы будут заблокированы операционной системой, если служба активна.
Выясним, как это сделать правильно. Откроем оснастку «Службы» (services.msc), найдем в списке Агент сервера 1С:Предприятие 8.3. Нажмем правую кнопку мыши и выберем «Остановить». Только после того, как статус службы сменится на пустой, можно запускать файл setup.exe из дистрибутива новой платформы.
При установке на сервере обязательно выберем компоненты:
Важно: При обновлении платформы в рамках одной минорной версии (например, с 8.3.10.2560 на 8.3.10.2667) настройки кластера, список баз и лицензии сохраняются в полном объеме. Файлы настроек обычно лежат в папке srvinfo, и инсталлятор их не трогает.
Несмотря на то что на форумах часто пишут, что проблем нет, мы проанализируем ситуацию глубже. Версия 8.3.10.2667 имеет ряд специфических особенностей, которые могут проявиться не сразу.
1. Ошибки XDTO и регистры бухгалтерии.
В ветке 8.3.10 была выявлена неприятная особенность: при использовании сложных механизмов обмена данными через XDTO могли некорректно заполняться измерения в регистрах. Если ваша конфигурация использует активную синхронизацию с другими базами (например, через РИБ), после обновления стоит провести выборочную проверку последних документов на предмет заполнения аналитики (например, субконто «Валюта»).
2. Требования прикладных решений.
Рассмотрим ситуацию: вы обновили платформу до 2667, но через неделю решили обновить саму «Бухгалтерию» или «ЗУП». Современные релизы конфигураций часто требуют платформу не ниже 8.3.12 или 8.3.14. Поэтому, выполняя переход, всегда сверяйте требования вашей текущей и будущей конфигурации в файле ReadMe.txt к релизу программы.
3. Драйверы защиты HASP.
Если вы используете аппаратные ключи (USB-флешки), при установке новой платформы система может предложить обновить драйвер Sentinel LDK. Будьте осторожны: иногда новые драйверы конфликтуют со старыми ключами. Если же вы используете программные лицензии (пин-коды), компонент «Драйвер защиты» при установке лучше вообще отключить — он вам не нужен и лишь создает лишнюю нагрузку и потенциальную уязвимость в сети.
Если ваши пользователи работают через веб-клиент (Apache или IIS), простой переустановки платформы недостаточно. Путь к библиотеке wsapch24.dll (для Apache) или аналогичной для IIS прописан в конфигурационных файлах веб-сервера и содержит номер версии платформы.
Разберем алгоритм действий после установки новой версии платформы:
Система автоматически обновит пути в файле default.vrd и перепишет настройки в конфигурации веб-сервера. После этого крайне желательно перезапустить саму службу веб-сервера (например, World Wide Web Publishing Service для IIS).
Многие ошибки после обновления, такие как «Ошибка формата потока» или внезапное закрытие программы, связаны с тем, что сервер пытается использовать старые временные файлы кэша для новых исполняемых модулей. Посмотрим, как правильно произвести очистку.
После остановки службы 1C:Enterprise 8.3 Server Agent, перейдем в каталог данных сервера (по умолчанию это C:\Program Files\1cv8\srvinfo). Внутри папок рабочих процессов (например, reg_1541) находятся папки с длинными именами-идентификаторами баз. Внутри них есть папки snccntx и conf. Удаление временных файлов в этих папках поможет избежать «глюков» после старта новой платформы.
Внимание: Никогда не удаляйте файл 1CV8Reg.lst, так как именно в нем хранится список ваших информационных баз и настройки кластера!
Обновив платформу, мы получаем доступ к новым возможностям, но конфигурация продолжает работать так, как будто она запущена на старой версии. Это регулируется параметром Режим совместимости в свойствах корня конфигурации.
Если мы планируем использовать новые фишки 8.3.10, нам придется изменить этот параметр. Однако это требует обязательного тестирования, так как некоторые функции встроенного языка могут начать работать иначе. Например, изменения могут коснуться работы с XML или механизмов формирования фоновых заданий. Если вы не разработчик, лучше оставить режим совместимости без изменений.
Подводя итог: процесс обновления платформы 8.3.10.2667 не является сложным, если соблюдать последовательность «Блокировка — Остановка службы — Установка — Очистка кэша — Запуск». Основное внимание стоит уделить проверке работоспособности специфических узлов (XDTO, веб-сервер) сразу после запуска системы.