Обновление платформы «1С:Предприятие 8.3» в условиях распределенной сети, когда пользователи находятся в других городах и подключаются через VPN, — задача нетривиальная. Основными препятствиями здесь выступают низкая пропускная способность каналов связи и необходимость синхронизации версий клиента и сервера. В этой статье мы подробно разберем, как организовать процесс обновления эффективно, минимизировав простои и риск возникновения ошибок.
Прежде всего, проанализируем текущую инфраструктуру. Важно понимать, какой тип клиентского приложения используют удаленные сотрудники: толстый клиент или тонкий клиент. Также определим режим работы базы данных — файловый или клиент-серверный. Рассмотрим основные правила, которых следует придерживаться:
Рассмотрим самый простой сценарий, когда мы просто устанавливаем новую версию платформы рядом со старой. Проанализируем, как работает механизм запуска 1cestart.exe. Эта утилита автоматически находит самую свежую версию платформы из установленных на компьютере и запускает ее, если в настройках конкретной информационной базы не указано иное.
Разберем ситуацию: если на сервере уже обновлена платформа до версии 8.3.25.XXXX, пользователю достаточно установить этот же дистрибутив. При следующем запуске 1С сама выберет актуальный релиз. Чтобы избежать проблем с правами доступа, рекомендуем выполнять установку от имени администратора. Не забудьте проверить настройки в окне запуска (кнопка «Изменить» — далее — далее), где в поле «Версия программы» обычно должно быть пусто или стоять 8.3.
Если ваши пользователи работают в управляемых формах, выясним, зачем им полная платформа. Дистрибутив тонкого клиента весит значительно меньше (около 200 МБ против 500+ МБ у полной версии). Это критически важно при передаче данных через VPN.
Тонкий клиент обладает функцией автоматического обновления с сервера. Если на сервере 1С настроена публикация дистрибутива, то при попытке подключения клиента с устаревшей версией система предложит скачать и установить обновление автоматически. Рассмотрим, как это настроить:
conf.cfg (который находится в папке bin/conf установленной платформы) пропишем путь к дистрибутиву.Для системных администраторов в доменной среде разберем метод массового развертывания. Это самый надежный способ обновить платформу у десятков пользователей в другом городе без личного участия каждого из них.
Сначала создадим административный образ платформы. Для этого запустим установку из командной строки с ключом /a:
setup.exe /a
В процессе будет запрошен путь, куда развернуть «чистый» инсталлятор. Полученный MSI-пакет мы можем опубликовать через Group Policy Object (GPO) в Active Directory. Разберем по шагам:
Проанализируем ситуацию, когда база опубликована через веб-сервер. После установки новой платформы на серверную машину необходимо обновить публикацию. Если этого не сделать, веб-сервер будет пытаться использовать библиотеки (например, wsap24.dll для Apache) от старой версии, что приведет к ошибке HTTP 500.
Воспользуемся утилитой webinst или зайдем в Конфигуратор от имени администратора и выберем пункт «Администрирование» — «Публикация на веб-сервере». Нажмем кнопку «Опубликовать». Это обновит пути в конфигурационных файлах веб-сервера.
Также не забываем про службу Agent 1C:Enterprise. После установки нового релиза на сервер Windows создается новая служба. Убедимся, что:
USR1CV8), что и предыдущая, чтобы сохранить доступ к каталогам кластера и логам.Часто после обновления пользователи жалуются на странное поведение интерфейса. Выясним причину: это происходит из-за того, что старый кэш несовместим с логикой новой платформы. Разберем скрипт для очистки кэша, который можно запустить удаленно:
rd /s /q "%LocalAppData%\1C\1cv8"
rd /s /q "%AppData%\1C\1cv8"
Что касается лицензий: при обновлении платформы в рамках 8.3 программные лицензии обычно не слетают. Однако, если вы используете аппаратные ключи HASP, проанализируем состояние драйверов. Иногда новая версия платформы требует обновления HASP License Manager и драйвера ключа защиты для корректной видимости лицензий в сети VPN.
Чтобы упростить жизнь пользователям в другом городе, рассмотрим использование общего файла списка баз. Вместо того чтобы прописывать путь к базе на каждом компьютере, создадим файл ibases.v8i на сетевом ресурсе, доступном через VPN. В настройках запуска 1С у пользователей укажем ссылку на этот внешний файл. Теперь при обновлении (например, если изменился адрес сервера или имя базы) нам достаточно поправить один файл в центре, и изменения мгновенно применятся у всех удаленных сотрудников.
Подводя итог, отметим: наиболее стабильный вариант для удаленных офисов — это сочетание использования тонкого клиента с настроенным автообновлением через веб-сервер или использование GPO для полной платформы. Это гарантирует единство версий и минимизирует ручной труд администратора.