В процессе администрирования крупных инфраструктур 1С системные администраторы часто сталкиваются с ситуацией, когда на серверную часть устанавливается новая версия платформы, а на рабочих станциях пользователей оказывается одновременно несколько версий (например, старая рабочая и новая подготовленная). В этот переходный период часто возникает критическая ошибка: "Различаются версии клиента и сервера". Рассмотрим подробно, как настроить механизмы 1С так, чтобы "стартер" (программа запуска) автоматически выбирал именно ту версию клиента, которая соответствует серверному кластеру.
Для начала проанализируем, как работает стандартный загрузчик 1cestart.exe. Когда пользователь запускает 1С через ярлык, ведущий в общую папку common, система не просто запускает оболочку, а выполняет поиск подходящей версии установленной платформы. Этот поиск базируется на данных из нескольких конфигурационных файлов. Если в этих файлах допущены ошибки или жестко прописаны неверные версии, автоматика ломается, и мы получаем сообщение о несоответствии версий.
Основными файлами, влияющими на выбор версии, являются:
Выясним причину, по которой 1С игнорирует нужную версию, даже если она установлена. В файле ibases.v8i, который обычно находится в профиле пользователя %AppData%\1C\1CEStart\, для каждой базы существуют параметры управления версией. Проанализируем их влияние:
Параметр Version жестко задает версию платформы. Если вы укажете полный номер, например Version=8.3.10.2580, то стартер будет пытаться запустить именно её, даже если на сервере уже стоит 8.3.12. Для обеспечения гибкости в период перехода рекомендуется указывать только мажорную версию.
Рассмотрим пример настройки информационной базы в файле ibases.v8i:
[Бухгалтерия предприятия]
Connect=Srvr="1c-server";Ref="buh_db";
ID=5351b965-4449-43dd-94f8-87263b62b974
OrderInList=1
App=Auto
WA=1
Version=8.3
Обратите внимание на строку Version=8.3. Если указать именно так, система выберет самую свежую установленную версию из ветки 8.3. Однако, если у вас на сервере 8.3.10, а на клиенте установлена 8.3.10 и 8.3.12, стартер по умолчанию попытается запустить 8.3.12, что приведет к ошибке связи с сервером. В этом случае на период миграции стоит временно прописать точную версию в параметре DefaultVersion или Version.
Проанализируем ситуацию, когда система "не видит" установленные платформы. Такое часто случается при использовании SCCM, если установка производилась в нестандартные каталоги или при смешивании 32-битных и 64-битных клиентов. Посмотрим на содержимое файла 1CEStart.cfg, который находится в %ProgramData%\1C\1CEStart\.
Чтобы стартер знал, где искать исполняемые файлы разных версий, необходимо проверить параметр InstalledLocation. Разберем правильное заполнение этого файла:
InstalledLocation=C:\Program Files\1cv8
InstalledLocation=C:\Program Files (x86)\1cv8
CommonInfoBases=C:\ProgramData\1C\1CEStart\ibases.v8i
AppAutoInstallLastVersion=0
Важный момент: параметр AppAutoInstallLastVersion=0 отключает принудительный запуск самой последней версии. Это позволяет системе более корректно отрабатывать требования сервера к версии клиента.
Рассмотрим наиболее профессиональный способ управления версиями в большой сети. Чтобы не править файлы ibases.v8i вручную на каждом из 250 компьютеров, мы можем задействовать механизм автоматической установки нужной версии с сервера. Для этого в общем конфигурационном файле 1cescmn.cfg (который можно раздать через GPO) указывается путь к дистрибутивам.
Алгоритм действий следующий:
\\Server1C\Distr).1CEStart.cfg или 1cescmn.cfg прописываем строку DistLocation=\\Server1C\Distr.Теперь, когда пользователь попытается зайти в базу, сервер сообщит стартеру: "Мне нужна версия 8.3.12.1567". Если стартер не найдет её локально, он обратится по пути DistLocation, сам установит нужную версию в фоновом режиме и запустит её. Это идеальный вариант для плавного переезда.
Посмотрим, как объединить все вышеперечисленные методы для массового сегмента. Для 250 машин лучшим решением будет использование скриптов или предпочтений групповых политик (GPP) для замены файла ibases.v8i или конфигурационных файлов. Разберем пример структуры файла ibases.v8i, который обеспечит стабильность при переходе:
[Управление Торговлей]
Connect=Srvr="1c-srv";Ref="trade";
App=ThinClient
Version=8.3.10.2580
DefaultVersion=8.3.10.2580
После того как вы обновите кластер серверов 1С до версии 8.3.12, вам достаточно будет одним действием в GPO заменить этот файл на новый, где будет указано Version=8.3.12.1567. Пользователи при следующем входе автоматически начнут работать на новой платформе без ошибок несовпадения.
Проанализируем сопутствующие проблемы. Часто даже при совпадении версий после перехода на новую платформу пользователи жалуются на странное поведение интерфейса. Это связано со старым кэшем метаданных. При массовой раскатке новой версии через SCCM рекомендуем добавить в сценарий завершающий этап — очистку временных файлов 1С. Достаточно удалить содержимое следующих папок:
%AppData%\1C\1cv8\ (папки с длинными UID именами)%LocalAppData%\1C\1cv8\Внимание: не удаляйте сами файлы конфигурации (.cfg и .v8i), удаляйте только папки кэша, чтобы не сбросить настройки списка баз пользователя.
Таким образом, мы выяснили, что для решения проблемы необходимо обеспечить правильные пути поиска в 1CEStart.cfg и точно управлять параметром Version в списке баз. Совместное использование этих инструментов позволит вам бесшовно перевести любое количество пользователей на новую версию платформы 1С.