Рано или поздно перед системными администраторами и руководителями ИТ-отделов встает задача оптимизации обслуживания парка компьютеров с установленной платформой 1С:Предприятие. Идея отказаться от классической локальной установки на каждой рабочей станции и запускать платформу напрямую из общей сетевой папки выглядит очень заманчиво. На первый взгляд, это решает главную проблему администрирования — необходимость регулярного обновления платформы на десятках клиентских машин. Достаточно обновить один каталог на сервере, и все 50 или более пользователей сразу начнут работать на новой версии.
Однако на практике этот метод таит в себе множество критических «подводных камней», способных полностью парализовать работу компании. Давайте детально проанализируем, почему прямой запуск платформы 1С из сетевой папки является опасной практикой, к каким последствиям это приведет при масштабировании на 50 пользователей, и как правильно решить задачу централизованного обновления с помощью штатных механизмов 1С.
Рассмотрим детально технические аспекты, которые делают запуск исполняемых файлов платформы 1С (таких как 1cv8.exe или 1cv8c.exe) непосредственно из сетевой папки крайне нежелательным решением.
Администратор рассчитывает на легкое обновление: просто заменить файлы в сетевой папке. Но в операционных системах семейства Windows при запуске исполняемого файла или динамической библиотеки (DLL) по сети происходит монопольная блокировка этого файла на сервере. Если хотя бы один из 50 пользователей оставит программу открытой (или у него зависнет фоновый процесс 1cv8.exe после некорректного выхода), перезаписать файлы платформы в сетевой папке будет физически невозможно. Администратору придется вручную принудительно сбрасывать активные сессии на файловом сервере, что полностью нивелирует всю декларируемую простоту обслуживания.
Если платформа 1С установлена локально, кратковременный сбой сети (например, на секунду пропал сигнал Wi-Fi или перезагрузился сетевой коммутатор) приведет лишь к временной потере связи с базой данных. В этом случае сработает встроенный механизм автоматического восстановления связи 1С, и пользователь продолжит работу. При запуске же платформы из сети ситуация принципиально иная: бинарный код и библиотеки DLL подгружаются в оперативную память компьютера пользователя динамически «на лету» по мере обращения к различным функциям интерфейса. Если в момент такого обращения произойдет даже микросекундное колебание сети, операционная система не сможет прочитать нужный участок файла. Это вызовет моментальный аварийный вылет приложения с ошибкой нарушения прав доступа к памяти (Access Violation), что приведет к гарантированной потере всех несохраненных данных пользователя.
Каждое действие пользователя, открытие новой формы или формирование отчета требует подгрузки определенных библиотек платформы. Скорость чтения данных даже по гигабитной локальной сети (1 Gbps) в разы ниже скорости чтения с современного локального накопителя SSD. В результате пользователи будут постоянно сталкиваться с микрозадержками при отрисовке элементов интерфейса. Ситуация усугубится в утренние часы («boot storm»), когда все 50 сотрудников одновременно придут на работу и начнут запускать 1С, перегружая пропускную способность сетевого интерфейса сервера.
При запуске платформы из сетевой папки на локальных компьютерах пользователей не регистрируются необходимые библиотеки в системном реестре Windows. Из-за этого полностью перестанут функционировать механизмы интеграции через COM-соединение (например, вызовы v83.COMConnector), которые часто используются для обмена данными между различными конфигурациями 1С, интеграции с сайтами или сторонним ПО. Также возникнут проблемы с подключением торгового оборудования и внешних компонент печати, требующих локальной регистрации DLL.
Современные политики безопасности Windows по умолчанию блокируют запуск исполняемых файлов из сетевых каталогов общего доступа или заваливают пользователя предупреждениями безопасности. Чтобы обойти это ограничение, администратору все равно придется настраивать групповые политики (GPO) для принудительного добавления сетевого пути в зону «Местная интрасеть» на всех рабочих станциях.
При запуске платформа пытается обращаться к сопутствующим конфигурационным файлам (например, файлам настроек защиты nethasp.ini) в своем каталоге. Если папка открыта для пользователей только на чтение (что правильно с точки зрения безопасности), платформа может выдавать ошибки при попытке инициализировать временные файлы. Если же дать пользователям права на запись в эту сетевую папку, возрастает риск случайного удаления или изменения системных файлов платформы кем-то из сотрудников.
Для решения задачи централизованного обновления без потери стабильности и производительности в платформу «1С:Предприятие» встроен штатный гибридный механизм. Он позволяет хранить дистрибутивы на сервере, но запускать и выполнять код платформы локально на компьютерах пользователей.
Давайте разберем по шагам, как настроить этот механизм автоматического развертывания.
Создадим на сервере общую сетевую папку (например, \\server-1c\1C_Distr) и предоставим всем пользователям права на чтение файлов в ней. В этот каталог мы будем выкладывать новые версии дистрибутивов платформы, распакованные из архивов (содержимое папки установщика, где находятся файлы 1cDist.msi, setup.exe и другие).
В этой же сетевой папке создадим текстовый файл с именем 1cescmn.cfg. Этот файл будет управлять поведением программы запуска. Пропишем в нем параметры автоустановки:
DistributiveLocation=\\server-1c\1C_Distr
CommonDst=1
InstallComponents=DESIGNERALLCLIENTS=0 THINCLIENTFILE=0 THINCLIENT=1 WEBSERVEREXT=0 CONFIDG=0
Разберем параметры подробнее:
DistributiveLocation — указывает программе запуска путь к сетевому каталогу, где лежат новые версии дистрибутивов.CommonDst — указывает, что при установке новой версии нужно использовать настройки по умолчанию.InstallComponents — определяет список устанавливаемых компонентов. В нашем примере мы отключаем установку толстого клиента и конфигуратора (DESIGNERALLCLIENTS=0), отключаем файловый вариант (THINCLIENTFILE=0) и устанавливаем только чистый тонкий клиент для работы в клиент-серверном режиме (THINCLIENT=1). Это позволяет минимизировать размер скачиваемого по сети дистрибутива и ускорить установку.На рабочих столах пользователей мы размещаем ярлык на общую программу запуска 1cestart.exe, расположенную в нашей сетевой папке (сам стартер весит очень мало, запускается мгновенно и не подвержен блокировкам). При запуске происходит следующее:
1cestart.exe считывает конфигурационный файл 1cescmn.cfg.C:\Program Files\1cv8\. Работа идет на максимальной скорости локального диска, обеспечивая полную стабильность и работоспособность всех COM-компонент.Важное преимущество метода: для такой установки пользователям не требуются права локального администратора на компьютере. Платформа 1С умеет устанавливаться в профиль текущего пользователя (в каталог %APPDATA%), если отсутствуют права на запись в Program Files.
Для наглядности сравним три основных метода организации работы 1С на 50 рабочих местах:
| Критерий сравнения | Запуск напрямую из сети | Административная установка (1cescmn.cfg) | Локальная ручная установка |
|---|---|---|---|
| Скорость работы интерфейса | Низкая (зависит от сети) | Максимальная (локальная) | Максимальная (локальная) |
| Стабильность при сбоях сети | Крайне низкая (вылеты приложения) | Высокая (автовосстановление) | Высокая (автовосстановление) |
| Сложность обновления платформы | Очень высокая (блокировки файлов) | Очень низкая (автоматически) | Крайне высокая (вручную на каждом ПК) |
| Работа COM-объектов | Не работают без доп. настройки | Работают без проблем | Работают без проблем |
Подводя итоги, мы можем сделать однозначный вывод: запуск платформы 1С напрямую из сетевой папки для 50 пользователей — это технологический тупик, который гарантированно приведет к нестабильной работе системы, постоянным аварийным завершениям программы у пользователей и головной боли администратора при попытках обновить платформу.
Для правильной организации работы необходимо использовать встроенный механизм автоматического развертывания через файл 1cescmn.cfg. Это обеспечит высокую скорость работы интерфейса за счет локального выполнения бинарного кода, стабильность сессий при колебаниях локальной сети, корректную работу COM-компонент и, самое главное, полностью автоматическое и незаметное для пользователей обновление платформы силами одного лишь системного администратора.