В этой статье я опишу способ подключения списка ИБ в зависимости от контролера домена авторизации пользователя при помощи скрипта cmd и групповой политики.
Преамбула: Статья была написано от лица программиста 1С для программистов 1С, которые отвечают за формирование списка ИБ 1С.
Цель: Сделать выбор необходимой пользователю ИБ 1С более простой и универсальной. Снизить необходимость участия системных администраторов при настройки системы формирования списка ИБ. Упростить настройку силами программистов 1С системы формирования списка ИБ в условиях изменения сетевой и серверной инфраструктуры.
Дано: Имеется главный офис и несколько обособленных подразделений (далее "ОП"), в каждом из которых есть свой контролер домена (далее "КД") и свой сервер "1С Предприятия". Между офисами постоянно перемещаются и работают в локальных РИБах сотрудники с личных или рабочих лэптопов. Системные администраторы гарантируют выбор локального КД при авторизации.
Задача: При авторизации пользователя в домене ему необходимо подключить список РИБов, развёрнутых в том ОП, в КД которого произошла авторизация.
Неудачное решение: Такие варианты решения, как указывать все РИБы в одном списке или делать на рабочем столе разные v8i списки баз для каждого ОП приводят пользователей к путанице и периодическим ворчанием вида:
"Ваша 1С [главного офиса] тормозит в ОП1"
"- Я всегда работал в этой 1С, а в ОП2 эта 1Ска тормозит.
— [объяснение].
— Какую другую 1Ску запускать? Вы меня запутали."
Оптимальное (на мой взгляд) решение:
Для автоматического изменения (по факту — пересоздания) файла "1CEStart.cfg" был сделан скрипт Set1CBases.cmd, который размещается в папке "\КонтролерДоменаГл
etlogon". Чтобы этот скрипт запускался при входе пользователя в систему была создана [глобальная] групповая политика для конфигурации пользователя (единственное требуемое от системных администраторов действие).
Листинг Set1CBases.cmd:
@echo off > Nul
@rem CMD скрипт для подключения списка баз 1С в зависимости от контролера домена, на котором пользователь прошёл авторизацию.
@rem Описание параметров взято с its.1c.ru компании ООО "1С-Софт" (с).
@rem Зломанов Глеб 07.2024.
@rem Установка кодовой страницы UTF-8 со скрытием вывода на экран.
@chcp 65001 > Nul
@rem Удаляем знаки \ из переменной среды LogonServer.
@set LogonServerName=%LogonServer:=%
@rem Наименование каталога на контролере домена где находятся (одноименные с контролерами домена) каталоги со списками информационных баз (файлами ibases.v8i).
set IBasesFolderName=ibases
@rem Наименование каталога с дистрибутивами платформ "1С Предприятия» на контролере домена.
set PlatformFolderName=Platform
@rem Заполнение общего файла 1CEStart.cfg.
@rem Первая строка с одним символом > для затирания существующего файла.
@rem Параметр содержит указание на каталоги, в которые выполнены установки «1С:Предприятия».
echo InstalledLocation=C:Program Files (x86)1cv82>"%APPDATA%1C1CEStart1CEStart.cfg"
echo InstalledLocation=C:Program Files (x86)1cv8>>"%APPDATA%1C1CEStart1CEStart.cfg"
echo InstalledLocation=C:Program Files1cv82>>"%APPDATA%1C1CEStart1CEStart.cfg"
echo InstalledLocation=C:Program Files1cv8>>"%APPDATA%1C1CEStart1CEStart.cfg"
@rem Параметр содержит указание на каталог, в котором будет производиться поиск новой версии для автоматической установки.
echo DistributiveLocation=%LogonServer%Sysvol\%UserDnsDomain%\%PlatformFolderName%>>"%APPDATA%1C1CEStart1CEStart.cfg"
@rem Параметр указывает путь и имя файла со списком общих информационных баз [текущего пользователя].
echo CommonInfoBases=%LogonServer%Sysvol\%UserDnsDomain%\%IBasesFolderName%\%LogonServerName%ibases.v8i>>"%APPDATA%1C1CEStart1CEStart.cfg"
@rem В конфигурационном файле содержится перечень установленных компонент.
@echo InstallComponents=DESIGNERALLCLIENTS=1 THINCLIENT=1 THINCLIENTFILE=0 SERVER=0 WEBSERVEREXT=0 CONFREPOSSERVER=0 SERVERCLIENT=0 CONVERTER77=0 LANGUAGES=RU>>"%APPDATA%1C1CEStart1CEStart.cfg"
@rem Параметр управляет поиском ключа защиты при запуске «1С:Предприятия».
@rem Символ #k8SjZc9Dxk используется для экранирования числа.
echo UseHWLicenses=#k8SjZc9Dxk1>>"%APPDATA%1C1CEStart1CEStart.cfg"
@rem Автоустановка новой версии «1С:Предприятия».
echo AppAutoInstallLastVersion=#k8SjZc9Dxk1>>"%APPDATA%1C1CEStart1CEStart.cfg"
Вместо текущего КД "%LogonServer%Sysvol\%UserDnsDomain%" можно указать сам домен "\%UserDnsDomain%Sysvol\%UserDnsDomain%", который переправит на ближайший КД, но по личному опыту — не советую.
Листинг генерируемого 1CEStart.cfg:
InstalledLocation=C:Program Files (x86)1cv82
InstalledLocation=C:Program Files (x86)1cv8
InstalledLocation=C:Program Files1cv82
InstalledLocation=C:Program Files1cv8
DistributiveLocation=\DC-SPBsysvolZZZ.LOCALPlatform
CommonInfoBases=\DC-SPBSysvolZZZ.LOCALibasesDC-SPBibases.v8i
InstallComponents=DESIGNERALLCLIENTS=1 THINCLIENT=1 THINCLIENTFILE=0 SERVER=0 WEBSERVEREXT=0 CONFREPOSSERVER=0 SERVERCLIENT=0 CONVERTER77=0 LANGUAGES=RU
UseHWLicenses=1
AppAutoInstallLastVersion=1
В каталоге корневого КД "\КонтролерДоменаКSysvolДомен" был сделан каталог ibases, внутри которого сделаны каталоги одноименные с наименованием серверов КД. Внутри каждого каталога был помещён файл "ibases.v8i" со списком баз того ОП, в котором физически располагается КД. Получились такие пути файлов:
"\КонтролерДоменаКSysvolДомен.СуфиксДоменаibasesКонтролерДоменаКibases.v8i"
"\КонтролерДоменаКSysvolДомен.СуфиксДоменаibasesКонтролерДомена1ibases.v8i"
"\КонтролерДоменаКSysvolДомен.СуфиксДоменаibasesКонтролерДомена2ibases.v8i"
"\КонтролерДоменаКSysvolДомен.СуфиксДоменаibasesКонтролерДомена3ibases.v8i
Положительные свойства решения.
У всех КД каталог "…SysvolДомен" [по умолчанию] синхронизируется (реплицируется) автоматически службой DFS-R, поэтому в кратчайшие сроки все файлы "ibases.v8i" были скопированы на другие КД, включая вложенную структуру каталогов и права доступа. При изменений в файлах или каталогах на любом из КД служба DFS-R реплицирует изменения на другие КД, что сильно упрощает поддержку актуальности версий списка баз на разных КД. Ещё одним из плюсов этого решения является то, что в любом ОП список баз всегда будет локальным и актуальным (при наличии связи между КД).
Настройка автоматического обновление платформы.
Также этим скриптом вы можете настроить автоматическое обновление платформы через дистрибутив, расположенный на КД. Для этого в "…SysvolДомен" необходимо сделать каталог (в скрипте у него наименование "Platform"), поместить в него все используемые дистрибутивами платформы "1С Предприятие" и указать название этого каталога в параметре "PlatformFolderName", а для параметра "AppAutoInstallLastVersion" выставите значение 1. Только не забудьте в соответствии с "Главой 10. Обновление системы" установить политику AlwaysInstallElevated для компьютера и пользователя, чтобы пользователь, не обладающий правами локального администратора смогли установить платформу. Также следует знать, что 1СEStart.exe при запуске попытается автоматически установить самую последнюю версию платформы, даже если она не будет использоваться. Предупреждение: репликация между КД большого объёма дистрибутивов платформы, расположенных в системной папке "sysvol" может замедлить репликацию групповых политик.
P.S. Если Вы захотите изменять вместо пользовательского файла "%APPDATA%1C1CEStart1CEStart.cfg" общий для всех пользователей компьютера файл %ProgramData%1C1CEStart1CEStart.cfg", то заранее продумайте как предоставить не локальному админу права на изменение этого файла. Возможно Вам пригодится утилита icacls.exe.
Во вложении сам файл Set1CBases.cmd для тех, кто хочет отблагодарить за статью.
Microsoft не рекомендует пользоваться системными папками для репликации своих данных, тем более для репликации и хранения дистрибутивов платформы. Ввиду ее большого размера это может привести к нарушению репликации групповых политик. Если Вы хотите использовать dfs для репликации данных — установите соответствующую роль, создайте доменный корень dfs, папку и определите набор репликации, а также его топологию.
https://www.forum.mista.ru/topic.php?id=726279
Для того, чтобы Ваши пользователи подключались к локальным ресурсам, на мой взгляд более правильным будет создать сайты Active Directory, для каждого сайта создать «дочернюю» зону и добавить туда cname записи Ваших локальных серверов, затем для каждого сайта создать политику, где Вы определите основной dns суффикс подключения. Таким образом, если в строке подключения будет написано srv=appsrv, то в офисе1 это имя будет разрешаться как appsrv.office1.domainname.domainsuffix, а в офисе 2 appsrv.office2.domainname.domainsuffix etc.
Ну и для распространения списка баз попробуйте расширение групповой политики
С его помощью Вы сможете создавать списки баз на основе групп windows т.е. Вам будет достаточно добавить пользователя в соответствующую группу.
Вот как то так.
(3)
Дык админы для того и нужны, чтобы администрировать, это их работа, настроить инфраструктуру так, чтобы работало как часы, а Вы пытаетесь минимизировать зависимость 🙂
Ну можно и микроскопом гвозди забивать, работать будет. Наверное не зря MS придумала DFS и дала Вам возможность ей пользоваться.
А кто у вас создает новые контроллеры доменов, программисты 1С, чтобы не беспокоить админов?
Вывод как мне кажется неверный. Если в определенном офисе у Вас нет КД или нет своих баз — вопрос решается опять-таки dns-суффиксом, который будет одинаковым с тем сайтом, где расположена база.
Это происходит без участия админов?
за правильный выбор КД в каждом офисе при авторизации.
Это и есть управление сайтами.
Для этого существует делегирование прав на изменение членства в группе.
Я понимаю, что Вы не админ и знать этих вещей не обязаны. В связи с этим могу лишь сказать, что с админами надо дружить и нормально взаимодействовать.
(4)
Свою работы они делают исправно, но список ИБ 1С НЕ входит в инфраструктуру, которую они должны поддерживать. Поэтому при изменении сетевой инфраструктуры админов не заботит, как будет работать создание списка «вашей 1С», потому что это полностью ответственность программистов. Зависимость программистов от админов это уже политический вопрос.
В итоге, для того «чтобы работало как часы» нужно большее количество знаний передаваться между админами, а в условиях территориальной распределенности, текучки кадров и различия в квалификации админов это становится проблематично. Кантовать главного админа можно только челобитной СЗ.
(4)
Нет, проблема в другом. Допустим в офисе1 есть база1 и база2, а в офисе2 только база1, а база2 должна быть подключена из офиса1.
(4)
Если микроскопом можно забить гвоздь со 100% вероятностью в любое время, а чтобы воспользоваться молотком нужно идти к админу, то я выбираю микроскоп. А админ доволен, что его молоток не кантуют лишний раз.
(4)
Опять вопрос политический: зачем нам, программистам, отвечать за «ваши ОЮщки и АДшки», у нас без этого работы хватает.
(5)Для этого существует делегирование прав на изменение членства в группе.
Опять вопрос политический: зачем нам, программистам, отвечать за «ваши ОЮщки и АДшки», у нас без этого работы хватает.
Так именно что даются права на администрирование конкретной группы (типа «Пользователи 1С», в которой уже могут быть ещё подгруппы) отдельному пользователю и можно самим программистам (даже из 1с) рулить этими правами не трогая админов.
Ещё пять лет назад так делали и список баз формировался просто включением пользователей в какую-то из групп («1С Бухгалтерия», «1С Продажи»…)