Легкое управление списками баз 1С

«Лучше день потерять, а потом за пять минут долететь» (с) м/ф Крылья, ноги и хвосты.



На «Хабре» есть три отличных поста про управление списками баз в 8.х:

1. «Управление списками баз 1С 8.2»;
2. «Как приготовить сотни баз 1С и не сойти с ума»;
3. «Управление списком баз 1С 8.2 с помощью Active Directory».

Каждый из них содержит свой кусок паззла от полноценной картины: Легкое управление списками баз 1С.

Пролог


Приведенная идеология построения позволяет легко масштабировать настройки, как для простых офисов с одним доменом, так и для мультидоменной структуры в составе леса. Конкретную реализацию решения каждый выбирает под себя сам, но здесь заложена основа чтобы без лишних усилий получить необходимую гибкость. Решение легко передается по наследству. Там нет скриптов. Совсем нет. Вообще.

Итак, с чем же мы боремся:

Пользователей стало много! – обойти 40+ пользователей с единой целью прописать новую базу или изменить настройки подключения у старой займёт приличное время. Хорошо, тем у кого есть бойцы техподдержки.
Баз стало много! – зоопарк баз, тестовые базы с легкой подачи 1Сников оказывающиеся в продакшне все еще находясь на серверах для тестирования. Умножаем на количество пользователей и ужасаемся.
Невнятные названия баз! — в этом месте, я каждый раз представляю, как своими руками душу очередного 1Сника за базу с именем «new2_baza2_copy» к которой привязана куча обработок, отчетов и СОМ соединений. Потому что ему показалось логичным ТАК назвать новую базу. Организация же одна и она внезапно не вырастет. И он один и все помнит. И никогда не уволится. А документацию ведут слабаки. Да это же всегда можно по быстрому переделать!
Частая ротация пользователей! – каждый новый пользователь не знает какие базы ему нужны (Часто звучит: «Мне нужны ВСЕ»), сотрудники часто меняют должности, подразделения, организации и как следствие свои обязанности.
Нагрузка! Скрипты! – сладостные скрипты сканящие весь AD леса в поисках определённых имен групп, чтобы подключить одну базу. А кто его написал? На чем? Когда? Где комменты?
Где мои базы?! – упс. Многие решения не позволяют сохранить индивидуальный список баз 1С пользователя и при этом использовать предопределенный набор баз.
Кластеры 1С? Сервера БД? – а есть разница? Их может быть больше одного. Разных версий 1С, разных баз данных. Техподдержка пытается найти концы, что бы точно понять что конкретно прописывать у пользователя на ПК.

Основную боль я описал.

Начнем?

Спойлер?
1. Вся представленная инфраструктура является тестовой и виртуальной. Любые совпадения с названиями юридических лиц являются случайными.
2. Простите меня за английский интерфейс на скриншотах с серверов. Я не мог иначе.
3. Поверьте мне, я руководитель группы системных администраторов, я знаю что я делаю! (с)


Шесть этапов до счастья:

Этап 1 — Инвентаризация

Берем табличный редактор и 1Сников. И подробно инвентаризируем, возможно, даже руками:

Рождается примерно такая таблица:



Наша задача понять, что где. Структурировать. Подробно расписать.

Этап 2 — Группы AD для баз 1С

Создание групп для баз в Active Directory, сразу пишем в описании используемый кластер и сервер баз данных:



На выходе получаем подробную информацию о каждой базе в структуре Active Directory. Указание имени базы данных в имени группы AD сильно облегчает поиск группы для определенной базы в больших инфраструктурах. Выделил пользователей, выбрал добавление в группу и указал нужное имя базы. Оп и все там. В то же время вашим коллегам (или наследникам) сразу будет видно какая группа AD за какую базу отвечает и где база находится.

Важно:
Помимо создания групп AD для каждой базы необходимо создать дополнительную группу AD «_Базы 1С – Доступ к файлу конфигурации 1CBases.cfg» — она поможет нам обеспечить доступ к файловому ресурсу, где хранятся конфигурации v8i всех необходимых нам баз. Включаем в эту группу все группы AD для баз 1С. Новые группы AD для баз 1С так же не забываем добавлять. Еще нам понадобится в её составе группа Domain Computers, чтобы дать возможность учетным записям ПК заходить на файловый ресурс. О нюансах ниже.



Этап 3 — Файлы конфигураций 1С

Инвентаризацию сделали, группы AD для баз создали, теперь файлы конфигурации v8i. Они хранят настройки подключения к базам: кластер 1С и имя базы в этом кластере.
Запускаем 1С. Если есть сформированный список баз, именуем их красиво и понятно.
Организация — Конфигурация — Версия конфигурации
Сохраняем их по правой кнопке в файлы, файлы именуем по имени базы. Заботливо накапливаем эти замечательные v8i файлы в одном каталоге. Если первоначального списка нет, можно создать одну запись в списке, она будет эталоном. С нее плодим новые файлы конфигурации v8i забивая необходимую информацию напрямую текстом в файл.

На выходе имеем файл с таким содержимым:



Избавляем каждый файл от лишних строк:



В итоге получаем определенное количество v8i файлов конфигурации, столько же сколько и баз.

Следующий шаг заключается в редактировании общего файла конфигурации баз для 1С.

По умолчанию в нем содержится совсем не перечень баз:



Проведем небольшие манипуляции, и в нем теперь указываются пути до всех файлов конфигурации v8i баз 1С.



Обращение к файлам v8i работает, как и с простой сетевой папкой на файловом сервере, так и с DFS ресурсом. Балансировка нагрузки, отказоустойчивость? Да! Знаем. Летаем.

В итоге имеем каталог полный файлов конфигурации v8i на каждую базу отдельно, плюс общий файл конфигурации в котором прописаны все пути до всех файлов конфигурации v8i.

Этап 4 — Файловый или DFS ресурс

Создаем каталог, в котором будут лежать файлы конфигурации v8i для подключения к каждой конкретной базе, а также общий список баз — файл 1CEStart.cfg:
именуем каталог Sync-1CBases.
Идеологический подход по доступу, к общим ресурсам, у всех разный. Многие предпочитают ставить на сам общий ресурс доступ Everyone — Full control, а дальше рулить доступом на уровне файловой системы. Так проще. Я предпочитаю отсекать доступ сразу на уровне самого общего ресурса, не создавая дополнительной нагрузки на файловый сервер лишними перепроверками возможности доступа.

На новый сетевой ресурс даем доступ группе «_Базы 1С – Доступ к файлу конфигурации 1CBases.cfg» права на чтение.

Божественные мануалы одной картинкой. Вместо тысячи слов.



Важно:
Дальше настраиваем безопасность на уровне файловой системы.

Самый первый шаг — это сброс настроек по умолчанию на объекты каталога Sync-1CBases. Отключаем наследование разрешений. Оставляем «SYSTEM», локальные Администраторы, Администраторы домена. Там, где есть лес можно добавить администраторов предприятия и/или делегированных администраторов. Получившийся результат применяем с наследованием. Тут же, не отходя далеко от кассы, добавляем группу AD «_Базы 1С – Доступ к файлу конфигурации 1CBases.cfg» с правом Чтение и только на этот каталог без наследования. На этом шаге мы получаем возможность добраться до корня папки и получить список файлов в каталоге.


До сих пор не привыкну к такому интерфейсу настройки прав доступа

Дальше самая соль:

На файл 1CEStart.cfg мы выдаем право на чтение только группе AD «_Базы 1С – Доступ к файлу конфигурации 1CBases.cfg»



Затем на каждый файл конфигурации базы v8i выдается доступ для своей группа доступа Active Directory:



Повторять последний шаг пока файлы конфигураций v8i баз данных не закончатся.

Этап 5 — Групповые политики

Очень многие не используют групповые политики. Многие используют их пренебрежительно мало. Зря-зря-зря. Это очень мощный инструмент облегчающий жизнь на работе даже в малых офисах.

Создаем новую групповую политику, линкуем её на корень домена. Указываем, что работает она только с Domain Computers:



Главное откровение (или нюанс) тут в том, что список баз подключается не по пользователю, а к ПК. К сожалению, пользователь не может с своими правами заменить файл конфигурации, находящийся в C:\ProgramData\1C\1CEStart\ и за него это сделает ПК.

Редактируем политику:



Здесь задача взять файл с общего ресурса и заменить локальный файл.
Что бы это делали только ПК с установленной 1С, задаем условия выполнения групповой политики через Item Level Targeting.

Проверяем наличие установленной 1С:



Это самая элементарная проверка. Проверяет как для х86 так и для х64 редакций операционных систем. Не делает различий между серверными и клиентскими ОС.

А вот сами условия проверки можно весьма широко варьировать, применяя эти настройки к определенным организационным подразделениям, в зависимости от условий доступности сетевых ресурсов и многим другим параметрам, что дает возможность максимально сузить условия срабатывания данной групповой политики.

Файл приводится в соответствие при загрузке ПК, либо раз в 90+- минут.

Этап 6 — Пользователь

Берем пользователя. И добавляем его в группы AD:



После чего производим вход пользователя в систему, запускаем 1С, которая считывает файл конфигурации и подключает все файлы v8i к которым у пользователя есть доступ. Результат:



Чего собственно и добивались.

При это данное решение не затрагивает файл C:\Users\%username%\AppData\Roaming\1C\1CEStart\ibases.v8i в котором хранятся базы, которые прописал сам пользователь. Впрочем, его всегда можно обнулить, чтобы почистить список баз у пользователя. Групповые политики вам в руки!

Эпилог

Формально я передал одну из множества вариантов реализации. Передал идеологию. Дополнительные решения к этой статье могут быть весьма широкими:
Автоматическое создание файла v8i, добавление его в cfg, создание группы AD для базы 1C.
Доступ для редактирования для специалистов по 1С для этих же файлов.
Проверка актуальности файла конфигурации cfg прежде чем заменять его на ПК.
Для параноиков можно создавать cfg файлы с предопределенными списками, а в v8i прописывать более одной базы. И вообще делать имена v8i файлов без указания на имя базы.
Можно изменить способ доставки cfg файла на ПК, где в конфигурации ПК изменяются права доступа к данному файлу, а пользователь уже с своими правами перезаписывает его.
И многое другое. Все что пожелаете. Каждый волен решать сам.

Итого:
Пользователей стало много! – не имеет никакого значения.
Баз стало много! – внесли базу 1Сники в реестр, пользователи её получили. Не внесли – база даже самоподключенная исчезнет у пользователя при следующем входе в систему, если включено обнуление списка локальных баз.
Невнятные названия баз! – какая разница? У тебя всегда актуальная информация. Нет полной информации о базе – нет базы у пользователей.
Частая ротация пользователей! – была заявка подключить базу? Есть база! Сменил место или подразделение, потерял базу вместе с сбросом прав.
Нагрузка! Скрипты! – где? Зачем? Балансировка, точное нацеливание, только актуальная информация, легкость обслуживания и поддержки.
Где мои базы?! – не положено! Ну или пользуйтесь пожалуйста. Все довольны.
Кластеры 1С? Сервера БД? – никакой путаницы. Все уже задано настройками. Технари заняты полезными делами, а не выяснением кому, куда и чего прописывать, как это обзывать и как не оставить пользователей с утра без учетной системы из-за обновления.

Постскриптум


Я потратил день. Чтобы вы за пять минут долетели. Спасибо!

Update:
Хабражитель — sisaenkov справедливо заметил, что вместо копирования cfg файлы в папку C:\ProgramData\1C\1CEStart\, для клиентских систем на базе Windows XP следует использовать переменную "%ALLUSERSPROFILE%\Application Data\1C\1CEStart\", в то время как для систем на базе Vista и старше можно использовать указанный в статье вариант, либо переменную %ProgramData%\1C\1CEStart\
Поделиться публикацией
Ой, у вас баннер убежал!

Ну, и что?
Реклама
Комментарии 33
  • 0
    Главное откровение (или нюанс) тут в том, что список баз подключается не по пользователю, а к ПК. К сожалению, пользователь не может с своими правами заменить файл конфигурации, находящийся в C:\ProgramData\1C\1CEStart\ и за него это сделает ПК.


    Не понял. Допустим, сам пользователь руками не может, но GPO preferences по умолчанию отрабатывают под системной учетной записью, даже если применяется политика «для пользователя» (для использования контекста безопасности пользователя надо специально настройку включать).

    Что бы это делали только ПК с установленной 1С, задаем условия выполнения групповой политики через Item Level Targeting.


    Если вы даже для сетевых шар придерживатесь политики «отсекать доступ на самом верхнем уровне» и даже сделали отдельный GPO для разлития файлика, то необходимые проверки было бы логично делать фильтром WMI, а не внутри самой политики. ;)
    • 0
      Системная учетная запись («SYSTEM») не может в сеть. Поэтому она ничего не заменит, посколько не доберется до файла лежащего в сети.
      Пользователь же не может заменить локальный файл из-за недостатка прав. Как вариант — сначала менять разрешения на файл, потом в контексте пользователя его копировать, но это уже один лишний шаг. Плюс, скажем на терминальном сервере появляется возможность злоупотребления путем редактирования списка баз. Редактирует один — страдают все.

      Фильтрация на вкус и цвет. Я же говорю, что важна сама концепция. Нравится WMI, используйте!
      • 0
        Системная учетная запись («SYSTEM») не может в сеть.


        Afaik, может, от имени учетки компьютера.
        • 0
          может, от имени учетки компьютера.
          и в этот момент в игру вступает системная учетная запись NETWORK SERVICE
          • 0
            Нет. Local System точно также действует в сети от имени компьютера (при использовании аутентификации Kerberos).
    • 0
      И ведь правы, пока все самое вкусное едят сидишь и настраиваешь базы… начал по вашему мануалу внедрять у себя. Спасибо!!!
      • 0
        Где вы были неделю назад?! Не пришлось бы писать скрипт.
        Главным откровением для меня стало то, что 1cestart.exe молча, не выводя никаких ошибок, игнорирует v8i файлы к которым не может получить доступ. Ключевая особенность решения я думаю.
        PS: а все знают, что %appdata%\1C\1CEStart\1CEStart.cfg имеет кодировку Unicode, а %appdata%\1C\1CEStart\ibases.v8i кодировку utf8? По крайней мере сама 1С их так создаёт.
        • 0
          Где вы были неделю назад?!
          В тот день я лег спать пораньше, простите! :)
        • 0
          зачем вы трогаете системные файлы, когда можно трогать %AppData%\1C\1CEStart\1CEStart.cfg
          Обращаю внимание, чтобы данный файл заработал, нужно чтобы ibases.v8i существовали (хоть пустые)
          • 0
            Да. Все верно. Вариант с изменением файла в профиле пользователя проще в реализации и логичнее применить его. Правда практика использования показала, что несмотря на то, что все выглядит логически просто, на практике первый запуск 1С слишком часто показывает отсутствие баз. Несмотря на наличие политики с ILT на создание файла ibases.v8i в случае его отсутствия.
            Терминальным пользователям с автостартом 1Ски отсутствие баз очень не понравилось, что привело к лишнему количеству заявок в Service Desk.

            С VDI не пробывал, но боюсь там эта беда будет помноженной на х100

            На семинарах Microsoft, на вопросы почему на ровном месте не отрабатывают групповые политики инженеры говорят, что все мои беды решит SC и позволит мне проконтролировать все нужные настройки. Троллят.
            • 0
              я добавил 5-секундную задержку перед 1Ской. прокатывает.
              Правда у нас настройка осуществляется через маленький клиент и вебсервер с сквозной авторизацией, также на основе групп, но нам была нужна фильтрация по IP
            • 0
              Вообще идея состоит в том, что 1С нужно знать только удалённый файлик .cfg в удалённом каталоге, а дальше всё понимается 1С кой на уровне прав доступа AD к файлам конфигурации.
              Глупо прописывть одну и ту же строчку каждому пользователя. А так вы делаете ссылку, смотреть там — всё…
              Если сеть из нескольких распределённых офисов и серверов 1С, то оптимальный путь до конфигурационной шары меняется только с переездом компьютера. Вообще на клиентском компьютере больше ничего не нужно делать в плане конфигурационных файлов списков баз.
              • 0
                Возможно не совсем уловил суть вопроса :)
                В статье указывается DFS путь до файлов конфигурации. Он решает сразу и вопросы филиалов и мультидоменной сети. Список баз постоянно меняется (в моём случае), как следствие на ПК должен располагаться актуальный список. Переезд компьютера — наименьшая из проблем. Возможность подключать базы организации находящейся в одном домене бухгалтерам или аудиторам из другого, опять же в моём случае очень частое явление. Таргетинг при этом решает проблему (т.е. не дает), когда человек пытается открыть базу находящуюся не в его локации не через терминал или v-app.
            • 0
              К сути статьи не имеет отношения. Но мои глаза начали кровоточить когда я увидел скрин из AD.
              Имена на кирилице, с пробелами, с нижним подчеркиванием в качестве первого символа.
              Очень в стиле 1С, но в остальном мире ИТ это моветон.
              • +1
                Когда то и я писал названия групп на английском :) у меня был один домен, и я там был единственный сисадмин.
                Сейчас почти вся структура на русском. Я даже объясню почему:
                — Проблем с совместимостью нет. Давно. Все программы поддерживают работу русскими именами в AD. nix системы в том числе.
                — Поддержка стуктуры AD в соответствии с штатным расписанием каждой организации не вызывает проблем.
                — Сверка выгруженной штатки из учетной системы для полуавтоматического сравнения с структурой AD не составляет проблем. (Должности, подразделения и т.д.) как следствие нет проблем с актуализацией данных в AD.
                — Структура, назначение групп интуитивно понятны тем у кого с английским не очень хорошо (например — аккаунт админам).
                — Нет проблем с взаимопониманием для чего и куда в большой (4+ чел) и распределенной команде сисадминов. Я не трачу время на объяснение очевидных вещей новичкам. Сторонние команды ИТ спецов (например — техподдержка) не испытывают проблем при диагностике неполадок на устройствах пользователей (пресловутый gpresult /h 11111.htm)

                — Имена групп, как правило, начинаются на "_" (подвал), это очень облегчает быструю выборку среди объектов AD в поиске без тыканья лишних галочек что искать нужно только среди групп. Это видно на примере скриншота в моей статье, где происходит выбор группы AD для назначения доступа к файлам v8i. Набрал "_Ба" — получил все группы с списками баз. Набрал "_До" получил все группы выдающие доступ. И так далее.

                Резюмируя: вся структура AD выстроена так, что бы быть логичной и интуитивно понятной, обеспечивающей быстрый поиск и управление объектами. А объектов AD под управлением моей группы очень много :)

                Четко построенная, логичная, быстрая работа это моветон в мире ИТ? Сомневаюсь.
                У Вас это пока привычка, дань моде… у меня же — функциональный порядок, проверенные временем и шквалом заявок, условия эффективной работы.
                Без обид, я делюсь ценным опытом.
                • 0
                  Не могу с вами согласится.
                  Для описания есть поле описание.
                  Написание на английском, причем с использованием минимального насколько это возможно без потери смысла, количества символов это общепринятая практика. Польза как минимум в том, что вам не нужно менять раскладку во время составления скрипта. А если мыслить чуть шире, то рано или поздно плоды вашей работы могут попасть к человеку не знакомому с кириллицей вообще.
                  Вы тратите 9 символов, только на то чтобы сказать, что это база 1с. Сами же потом приводите пример. По факту вы ищете по 3 символам. А если бы избавились от нижнего подчеркивания, хватило бы и двух.
                  Дальше у вас длинное описание базы на русском, а в скобках на английском. Зачем? Эта информация дублируется в описание.
                  db_venus_ut — дает полное представление о том, что это и зачем. Также легко ищется по первым двум знакам. Если когда-нибудь потребуется писать скрипты и обрабатывать вывод, преимущество монолитных английских имен будет очевидно перед 40 символьным русско-английским с пробелами.
                  Вы приводите еще пример не владеющих английским… Это мне крыть нечем.)
                  ЗЫ. Тоже надеюсь не сказал обидного ничего. Метафора про глаза, исключительно из личного опыта. Потому что мне приходилось в процессе автоматизации парсить вывод системы настроенной в похожем ключе. И я все не мог понять… ну зачем. Ведь можно просто обрезать 90% имени и нисколько не потерять в информативности.
                  • 0
                    Аргументированные доводы это всегда хорошо! :)
                    Я не работаю в мультинациональной трансатлантической корпорации, где английский является рабочим языком. Зато русскоговорящих вокруг — каждый первый. Когда это случится перейду на новые стандарты, мне не сложно.
                    Насчет скриптов, есть только один недостаток — они становятся в некоторых случаях просто монструозными на вид, хотя на их функционал это не влияет. Переключение раскладки при слепом методе печати — просто две дополнительные кнопки. Я за это время даже руку с клавиатуры на мышку переместить не успею :)
                    Что до людей не знакомых с кириллицей: я же умудряюсь разобраться в примерах решения на PowerShell, скажем, с итальянских или немецких форумов, хотя этими языками не владею.
                    Вы тратите 9 символов, только на то чтобы сказать, что это база 1с. Сами же потом приводите пример. По факту вы ищете по 3 символам. А если бы избавились от нижнего подчеркивания, хватило бы и двух.
                    Опять вопрос методики по быстрой работе: при выборе объекта зайти в Object Types, выбрать нужный вид и применить область действия. Минимум три дополнительных клика.
                    … или поставить "_" перед именем и гарантированно получить выборку по группам. Каждый решает сам :)
                    Дальше у вас длинное описание базы на русском, а в скобках на английском. Зачем?
                    Читаемость, понятность. Имя на русском это то как группу запрашивают пользователи. В скобках имя базы к кластере 1С/сервере баз данных. Оно обычно озвучивается уже 1Сниками для исключения путаницы баз. Проблем с восприятием и пониманием у ИТ специалистов нет.
                    Эта информация дублируется в описание.
                    Ну в описании как раз идет отсылка на используемый кластер и сервер баз данных. Не вижу там дубляжа.
                    db_venus_ut — дает полное представление о том, что это и зачем.
                    Я почти согласен. Но вернемся к реалиям. Есть базы new2_baza2_copy и new2_baza2. С ними то мне что делать? Они рабочие и имена их я поменять не могу, вернее могу, но все сломается :) А описание к базе доступно не везде при выборе групп AD. Сейчас у меня таких «наследных» баз более 60+. Добавлять еще один англоязычный алиас? Это нужно документировать, поддерживать, тратить время. А зачем это документировать, если можно в AD разместить актуальную информацию и по необходимости генерировать отчеты напрямую с AD?

                    Я повторюсь. Пока я был один в своей инфраструктуре, я все знал досконально. Сейчас у меня если специалист закрепленный за группой обслуживаемых организаций уходит в отпуск, то я без проблем могу его заменить другим специалистом, или раздать его заявки на нескольких человек. При этом никому не нужно искать документацию, таблицы соответствий и прочие вещи, напрягать звонками отдыхающего человека что бы понять, где что находится. Все сразу в AD, на виду, на понятном языке не допускающим двойных толкования и неточностей перевода. Работа продолжается в штатном режиме.
                    • 0
                      В вашем конкретном случае это работает и не создает проблем.
                      Хороший пример new2_baza2_copy. Человек который это придумал не видел перспективы. Для него это работало. Но вам теперь нужны комментарии, чтобы понять о чем идет речь.
                      Насчет групп и нижнего подчеркивания. Db вполне достаточно для поиска, выбирать поиск только по группам нет необходимости. В худщем случае, вы получите пару лишних пользователей, если например у вас есть кто-то с фамилией начинающейся на 'дб', и то они будут в конце списка.
                      И насчет восприятия тоже очень спорно. Мозг прекрасно понимает сокращения русских слов даже на латинице.
                      Это все конечно же оффтоп, которому место в отдельной статье о именованиях.
                      • 0
                        Хороший пример new2_baza2_copy. Человек который это придумал не видел перспективы. Для него это работало. Но вам теперь нужны комментарии, чтобы понять о чем идет речь.
                        Баз много, 1Сников много. 1Сников я проконтролировать не могу, а вот своих подчиненных — да.
                        Db вполне достаточно для поиска
                        Вяло тянет на общемировую практику, но фактически мы говорим об одном и том же — метка для группы с базой данных. Каждый реализует её как хочет. На вкус и цвет :)
              • +1
                Для Windows XP необходимо указывать: %ALLUSERSPROFILE%\Application Data\1C\1CEStart\1CEStart.cfg
                Ибо переменная %ProgramData% появилась только в Vista.

                Проверено опытным путём.
                • 0
                  Спасибо! Исправил!
                  • 0
                    Кстати, в Windows 7 путь %ALLUSERSPROFILE%\Application Data\1C\1CEStart\ также ведёт в нужную папку, так что для универсальности можно использовать его с обоими ОС.
                  • 0
                    Я чуть-чуть слоупок(Избранное — зло), но не увидел ни у автора, ни в комментах одной маленькой рекомендации
                    Если вы вручную создаёте v8i-файлы — проверьте, чтоб в файлах не совпадали ID у разных баз. Это может вызывать очень странные коллизии. Какие — не помню, однажды убил почти час, пока не нашел причину проблемы, с тех пор просто взял за правило поменять пару символов в ID как минимум при копипасте внутри v8i.
                    • 0
                      В статье рекомендуется сточку с ID удалять, в шаблоне она тоже отсутствует, как раз для решения этой проблемы.
                    • 0
                      Невнятные названия баз! — в этом месте, я каждый раз представляю, как своими руками душу очередного 1Сника за базу с именем «new2_baza2_copy» к которой привязана куча обработок


                      Мы эту проблему решили кардинально — 1С ник не может сам создавать базы. Только через заявку системному администратору. А уж тот с него вытрясет для чего и зачем база нужна. Либо не даст базу.

                      Периодически тот же системный администратор делает инвентаризации и в случае обнаружения «левых» баз их удаляет, предварительно уведомив 1С-ников.
                      • +1
                        С новыми все нормально, вопрос больше про наследные базы.
                        • 0
                          Глупо вешать всё на админа, когда можно настоить и передать 1С'нику. Суровые реалии нашего рынка диктуют другие условия.
                          1С разработчик, он же по совместительству и админ 1С, он контролирует заведение пользователей в 1С, он принимает решение об переносе функционала в отдельную базу, конфигурацию. И нужно лишь ему немножко помочь, чтобы он в очередной раз не мучил тебя просьбой подключить кому-то каую-то базу, а потом её отключить… или поменять настройки подключения к базе… Эта кухня не нужна админу… И во многих организациях, даже ооочень крупных, админы почти не занимаются администрированием 1С. Это я взял не из головы, а практика, которую я вижу.
                          А к вашим словам, что 1С'ник не может создать базу своими руками… Он очень легко может наколхозить под пользователем сотрудника, придя за компьютер… И вот тут, вы пятнадцать раз пожалеете, что не научили этого колхозника работать со списком баз правильно, и не дали его в руки инструпент для правильной работы. Это тоже личный опыт. Потому что он сначала навертит, а потом, когда неполучится, придёт к вам, и вы будете всё это говно разгребать, как админ всия компании!
                          Про инвентаризации… Если у вас есть настолько дешёвые ресурсы админа, что ему больше заняться не чем, как инвентаризировать срач плодящийся регулярно, то пожалуйста. Или у вас текуча бешенная среди админов, которым приходится, регулярно лазить и раскапывать эту фигню, связываться с 1С'никами и вызнвать, какая тут хрень для чего нужна, в то время, когда этим ребятам нужно спешить, и некогда учиться летать, поэтому документации даже своей служебной они не пишут. Это тоже личный опыт.
                          • 0
                            Ну реалии я как вижу у всех разные.
                            У нас вся работа построена через сервисдеск, никто никого не мучает. Указанная в статье структура работы для нашего случая оптимальна. Все стандартизировано, и понятно даже новичкам как от админов, так и от 1Сников. Заявка пришла, её отработали.
                            У нас не ходят ножками за ПК пользователей, ибо они раскиданы по области, а наш активно растущий офис в обособленном здании :) а еще их (1Сников) у нас сильно больше одного, не говоря о том, что моя группа работает и с 1Сниками многих, а не только нашей, организаций.
                            Инвентаризационные циклы в обслуживаемых организациях мы всеравно проводим, и в них входят не только базы 1С: админы свое перепроверяют, 1Сники своё, техподдержка своё. Это нормальный циклический процесс в рамках работы аутсорсера.
                        • 0
                          Прекрасная аккумуляция накопленного знания! Это я об этой статье.
                          Мой личный опыт привёл меня к мысли о наименьшем завязывании на групповые политики. Факт остаётся в том, что они очень медленные по скорости реакции на событие и распихивать ими действительно можно только ссылочки на файлик конфигурации на уровне всей клиентской машины для всех пользователей.
                          Эта статья о полном захвате власти над управлением списком баз 1С админом. В AD вы не пустите 1С разработчика, и не будете его обучать, как ей пользоваться… А лопатить всё самому за них — права, не стоит.
                          Я сделал всё проще. Я так же разграничил доступ к файлам на уровне парав пользователей AD в файловой системе, и совершенно не засирал AD лишней информацией о группах, базах и прочей хрени. Просто даёте права правки изменения на каталог с конфигурационными файлами 1С разработчику или группе этих оболтусов, обучаете основному принципу, как это работает, и забываете об этом, как о страшном сне.
                          Так нужно сделать по уже описанным выше комментариям… 1С разработчик, в большинстве компаний — он же и админ 1С баз, серверов, техподдержка пользователей в части 1С…
                          Вот единственный ключевой момент о котором стоит позаботиться сразу, так, это ссылка на шару с конфигурационными файлами на клиента обязательно должна быть ссылкой в dns на реальный адерс. И тогда, вам вообще не нужно будет использовать GPO для изменения ссылки на конфигурационную шару. Всё правление перемещается в DNS. Если вы, вдруг вздумаете перенести шару на другой сервер, то вам всего лишь достаточно поменять DNS запись синонима. Это прорывная идея, я вам скажу, которой я очень горжусь.
                          Вообще хотел обновление своей статьи сделать, часть 2 — так сказать. Но времени нет вырисовывать всё это. Поэтому решил отписаться самым ядром идеи здесь в комментарии.
                          Поверьте не стоит засирать AD этим мусором, который вы не разгребёте с увеличивающимся количеством пользователей, баз, 1С разработчиков, кластеров. Просто отдайте эту кухню им и скажите, что у них есть все возможности для манипуляции с доступом к базам. Это куда продуктивней. А ваша работа должна сводиться к следующим моментам:
                          — Создать конфигурационную шару,
                          — набить конфигурационными файлам,
                          — раздать права ответственным,
                          — на все компьютеры клиентские в общепользовательский каталог напихать ссылку на ссылку в DNS на запись о конфигурационной шаре.
                          — обучить «этих бездельников» работать с этим.

                          Единственная работа которая вас ждёт в дальнейшем с этим, это перенос конфигурационной шары на другой сервер. Тогда, вам, прямо, предстоит титанический труд:
                          — скопировать шару с правами, как есть,
                          — изиминить ссылку на шару в DNS.

                          Вот это будет дичайшая автоматизация процесса. Это с позиции Админа.
                          С позиции 1С разработчика, тоже всё удобно, они сами рулят тем, чем рулили, только в более полной мере, и им не нужно повышать права в системе хоть на сколько нибудь.

                          P.S. «Бездельники» взяты в кавычки… Не нужно подымать рёв. Я не считаю 1С разработчиков бездельниками… Может, лентяями, но не бездельниками. Об их тяжёлом труде я знаю не по наслышке — сам сейчас работаю 1С программистом.
                          • 0
                            Ох.
                            1С разработчик, в большинстве компаний — он же и админ 1С баз, серверов, техподдержка пользователей в части 1С…
                            У нас, 1Сники (аромя прогерства и методической работы) отвечают только за работоспособность серверной части 1С и СЛК к ней. Админы рулят всем остальным. Имхо, это оптимальный для всех подход.
                            Всё правление перемещается в DNS. Если вы, вдруг вздумаете перенести шару на другой сервер, то вам всего лишь достаточно поменять DNS запись синонима. Это прорывная идея, я вам скажу, которой я очень горжусь.
                            Полагаю разговор идет о CNAME-записи. На мой взгляд DFS куда практичнее.
                            Вообще хотел обновление своей статьи сделать, часть 2 — так сказать. Но времени нет вырисовывать всё это. Поэтому решил отписаться самым ядром идеи здесь в комментарии.
                            Я бы с интересом почитал статью, реальный опыт и оптимальные решения всегда интересны.
                            Поверьте не стоит засирать AD этим мусором, который вы не разгребёте с увеличивающимся количеством пользователей, баз, 1С разработчиков, кластеров.
                            Зря Вы так. AD для того и создано. Я всегда вижу какому пользователю какая база подключена. Очень удобно при аудитах прав доступа.
                            Просто отдайте эту кухню им и скажите, что у них есть все возможности для манипуляции с доступом к базам.
                            А они сами не хотят брать. Они хотят прогать, а не настраивать разрешения в папках. И я с ними согласен, не их это.
                            — на все компьютеры клиентские в общепользовательский каталог напихать ссылку на ссылку в DNS на запись о конфигурационной шаре.
                            вот тут бы подробностей побольше.
                            скопировать шару с правами, как есть
                            мне несложно добавить, ключ /SEC в команду для robocopy.exe
                            Вот это будет дичайшая автоматизация процесса. Это с позиции Админа.
                            Вы просто переложили свою задачу на чужие плечи.

                            Пока что, схема работы описанная в статье, остается актуальной и самой простой на данный момент. Если кто ткнет меня в статью описывающую более удобный механизм работы для аутсорсера, я был бы только рад.
                          • 0
                            О первым же замечаниям вижу, что у вас порядок в компании, все на своих местах.

                            Полагаю разговор идет о CNAME-записи. На мой взгляд DFS куда практичнее.
                            DFS? А что это такое? (сарказм) На сколько его используют в компаниях? На сколько он хорош на нестабильных соединениях распределённых сетей по удалённым уголкам планеты?
                            И это ещё одна технология с которой предстоит разобраться человеку, хотя польза в ней сомнительна… Это моя личное мнение. Вполне возможно, что я ошибаюсь.

                            Зря Вы так. AD для того и создано. Я всегда вижу какому пользователю какая база подключена. Очень удобно при аудитах прав доступа.
                            Это при условии, что у вас там строгий порядок, а не кучка админов по необходимости на свой лад, по просьбе программиста добавляет права шибко не разбираясь в чужой кухне. Мой вариант для слабо организованных систем. Никто не умоляет удобства и возможностей LDAP, AD. Но на своей практике я видел только мусорку там. Пояснить назначение всех групп, OU'шек мне не могли, и не документировали нифига.
                            Вы просто переложили свою задачу на чужие плечи.
                            Нет же! Я помог навести порядок и организовать работу. 1С программисты, может и не любят работу с правами пользователей, но активно организуют систему прав доступа, и раздают права налево и направо… А когда не могут дозвониться до админа, или скорость его реакции ниже ожидаемой, то проще ручками наколхозить у заказчика с базами… Надо же быстро сейчас проверить, а потом может быть убрать. Я ещё раз повторюсь, порядка в организации процесса очень мало в организациях. Если вам этот порядок удалось организовать, то я только рад.

                            на все компьютеры клиентские в общепользовательский каталог напихать ссылку на ссылку в DNS на запись о конфигурационной шаре.
                            вот тут бы подробностей побольше.
                            Вот объяснение:
                            На пользователях по пути "%ProgramData%\1C\1CEStart\1CEStart.cfg" в довесок к тому что там имеется по умолчанию кладёте вот такую вот строчку:
                            CommonCfgLocation=\\server.exemple.ru\СпискиБаз\1CEStart.cfg

                            В файле, на который мы ссылаемся выше (\\server.exemple.ru\СпискиБаз\1CEStart.cfg) пишем ссылки на наши базы:
                            CommonInfoBases=1СБухгалтерия.v8i
                            CommonInfoBases=1ЗУП.v8i
                            ...

                            В этом файле (\\server.exemple.ru\СпискиБаз\1CEStart.cfg) путь можно указывать относительно его местоположения, поэтому я сэкономил время и байты памяти, чтобы не калякать весь полный путь. Синтаксис файлов *.v8i, думаю вам не стоит разъяснять.
                            Каждый такой файл *.v8i содержит в себе информацию об одной базе. Это идея такая. Я заню, что туда можно написать сколь угодно баз. Но моя идея в том, чтобы одна база — один файл. Тогда если разработчику или админу нужно поменять настройки подключения к базе, то он правит только этот файл один раз, и всё! После этого после перезапуска клиента люди будут цепляться по новым параметрам. И самое важно, чтобы эти базы не плодились копиями по филиалам. Т.е. Есть кластер 1С, рдом с ним в одной сети находится конфигурационная шара с такими файликами, декларирующая подключение к базам 1С этого кластер. И если у нас появились пользователи с удалённого офиса, где-нибудь в запедрыщинске, то мы им им по первому пункту этого разяснения в общепользовательский каталог пихаме запись на эту шару (у него таких шар может быть записана хоть тыща). И он также автоматом узнаёт об этой базе, если у него есть права на чтение этой конфигурационной шары и файликов. Вот такой не сложны принцип самоорганизации. И у вас появляется распределенная система конфигурационных файлов, ответственных над которыми вы ставите по регионам, т.к. они будут сами там реорганизовывать и ломать у себя что-то и зачем вам вникать в их кухню. А так, как организовали вы, это можно делегировать только админам, да ещё и не простым, а которые понимают, что делают в AD. При моей же схеме вы можете это доверить даже эникею, программисту — ну в крайнем случае — бухгалтеру (но тогда успех не гарантируется (сарказм)).
                            Надеюсь понятно раскидал. Поиграйтесь с этим, и вы поймёте гибкость моего решения. Главное не забывайте про CNAME… без него будет всё не так красиво и легко.

                            Там вы ещё про копирование с ключами говорили и что это очень легко… Но, ведь правда же, что вообще не шевелить данные без необходимости куда практичней и проще…

                            Кстати одна из болезней 1С разработчиков, это любовь к реорганизации базы данных, перестроения таблиц, справочников — будто это файлики какие-то. И от этого все их проблемы. Данные хорошо записывать один раз и не менять их местоположение, тогда не нужно будет переписывать весь свой код занова… Но тогда у нас не будет работы.
                            И с вашей автоматизацией очень хорошо подчёркивается важность системного администрирования, и наличия Администратора, AD, DFS (что это?! (сарказм))… А! ещё и групповые политики тоже очень нужные!..
                            А при моей «колхозной автоматизации» вам всё организовать придётся раз, делегировать кому-то и забыть. Понимаете! Забыть! Оно само будет работать без AD, без GPO, без Администратора, без DFS… Хорошо бы ещё и Window нафиг снести… (сарказм).
                            Надеюсь из всего моего потешательства, вы увидели главную идею и вынесли полезное.
                            Буду рад, если этот опыт, действительно кому-то сэкономит 100-200 часов работы, может больше. Всё зависит от того, сколько времени вы с этим будете работать и как.
                            • 0
                              а не кучка админов по необходимости на свой лад, по просьбе программиста добавляет права шибко не разбираясь в чужой кухне. Мой вариант для слабо организованных систем.
                              Если эникейщик управляет сервером это не делает его админом.
                              Пояснить назначение всех групп, OU'шек мне не могли, и не документировали нифига.
                              Ровно так же потом не смогут пояснить откуда и чего людям подключается в 1С.
                              Мы тоже группы не документируем где либо отдельно. Мы даем понятные названия группам, и подробно описываем в описании к группе. Этого вполне хватает.
                              Вот объяснение:
                              На пользователях по пути "%ProgramData%\1C\1CEStart\1CEStart.cfg" в довесок к тому что там имеется по умолчанию кладёте вот такую вот строчку:
                              CommonCfgLocation=\\server.exemple.ru\СпискиБаз\1CEStart.cfg

                              В файле, на который мы ссылаемся выше (\\server.exemple.ru\СпискиБаз\1CEStart.cfg) пишем ссылки на наши базы:
                              CommonInfoBases=1СБухгалтерия.v8i
                              CommonInfoBases=1ЗУП.v8i
                              Скажу сразу, что сходу у меня по данной схеме реализовать не удалось. Покурю мануал получше, видимо нюансы с подключением есть.
                              Решение было бы очень удобным в контексте того, что на оконечных ПК не нужно обновлять 1CEStart.cfg, и все изменения в корневом файле бы применялись мгновенно.
                              Спасибо за наводку.

                              А при моей «колхозной автоматизации» вам всё организовать придётся раз, делегировать кому-то и забыть.
                              Все бы хорошо, но опять приходим к ситуации, когда вы отдали и забыли, а на местах люди сменились и им ничего не передали. В итоге носителей информации ноль.

                              И может я не до конца понял, но у вас к v8i файлам доступ прописывают 1Сники. Допустим к базе требуется доступ 150+ сотрудникам. Их там поименно в доступе прописывают что ли?
                            • 0
                              Все бы хорошо, но опять приходим к ситуации, когда вы отдали и забыли, а на местах люди сменились и им ничего не передали. В итоге носителей информации ноль.
                              Документация для этого делается один раз.
                              И может я не до конца понял, но у вас к v8i файлам доступ прописывают 1Сники. Допустим к базе требуется доступ 150+ сотрудникам. Их там поименно в доступе прописывают что ли?
                              Да хоть как! Можете поимённо, можете группам давать. Не мне вас AD учить… Главное, чтобы у человека были права на назначение прав в каталоге. Интересные ему группы он может себе записать, или вы ему списочек с объяснением дадите. Но опыт показывает, что о назначении групп все со временем забывают, и добавляют человека напрямую так, чтобы наверняка и лишнего доступа не дать. Колхоз! Я вам говорю про среднестатистическую фирму с полным бардаком. Вашу, крутейшую организацию я не берусь здесь рассматривать.
                              Скажу сразу, что сходу у меня по данной схеме реализовать не удалось. Покурю мануал получше, видимо нюансы с подключением есть.
                              Нет никаких нюансов с подключением. Там вообще никаких высших механизмов не задействовано. Курить там не чего. И объяснил я, вроде уже на пальцах. Смотрите кодировку файла. Если это не UTF-8, то этот файл не видится. Я сам регулярно напарывался на то, что в редакторе не смотрел, какая кодировка стоит при сохранении файла, и перекодировал файл в… Какая там кодировка по умолчанию в русской винде?..
                              Решение было бы очень удобным в контексте того, что на оконечных ПК не нужно обновлять 1CEStart.cfg, и все изменения в корневом файле бы применялись мгновенно. Спасибо за наводку.
                              За наводку пожалуйста. Решение тем и гениальное, что скорость реакции на изменения ровно после нажатия кнопки сохранить в окне выставления прав пользователей или редактирования конфигурационного файла. Групповы политики так никогда не смогут. Идеальный порядок на пользовательских станция (там просто ничего нет, кроме одной строчки), и у вас засрать эту систему можно, как угодно, а потом причесать, как угодно, и пользователь не будет об этом знать. Если, вдруг, лажанул админ, и после реорганизации, кого-то не добавил, то он это делает по звонку целовека, просит пользователя переоткрыть 1С, и в списке появляется нужная база. Если база не появляется, то тут либо проблемы с правами, либо совсем нет связи с сервером, либо связь есть, но она такое говно, что 1С не дождалась ответа при запросе к файлу (а это должны быть потери конские, или пинг не менее конский).

                              И вот этим вы меня сильно зацепили:
                              Если эникейщик управляет сервером это не делает его админом.
                              Если человек админ, это не значит, что он всё уже знает о своей области.
                              Вот, например вы эникеите в области, которую мы с вами здесь обсуждаем. Т.е. тыкаетесь, на основе своего уже имеющегося опыта, не читая документацию и не делая экспериментальных постановок, не анализируя эффективность и лёгкость вашего решения.
                              И действительно, это очень маленькая задачка, чтобы придавать этому такое большое внимание. Поэтому вы её вывели на верхний уровень администрирования с AD, GPO, DFS (Что это такое?! (сарказм)) и прочим хламом. А я её упростил до эникея, с наименьшими затратам по технологиям, и правками в различных местах одних и тех же файлов. Там всё гениально и просто. Это я не про то, что я придумал, а про то, что разработчики продукта 1С так гениально постарались и продумали. Проблема в том, что они нормально это не описали. И мало кто знает, как гибко это можно организовать.
                              Прошу прощения, если обидел последними строками.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое