Место создания и центр 1с

Обновлено: 07.07.2024

Классическая структура УРИБ - звезда. Т.е. одна база центральная (ЦБ), несколько периферийных (ПБ). Данные между ПБ могут переносится только через ЦБ.

Периодически всплывают вопросы о построении более сложной структуры данных. Буквально 21.07.2004 на форуме Т1С был задан вопрос: "Каким образом сделать для ПБ еще одну, подчиненную ИБ" *. Решение этой проблемы могло бы иметь огромное практическое применение.
Поэкспериментируем.
Для начала заводим ЦБ и одну ПБ (ПБ1). Делаем первую выгрузку из ЦБ в ПБ, в ПБ, соответственно загружаем исходные данные. Теперь смотрим таблицу 1SDBSET в только что загруженной ПБ. Если изменить значения полей, как показано на рисунке, то наша ПБ превратится в ЦБ! Теперь открываем конфигуратор и заводим для нее подчиненные ПБ. Вот вам и "узел" ПБ!

  • ЦБ 1SDBSET.DBF - текущая ИБ - центральная
  • ПБ 1SDBSET.DBF - текущая ИБ настроена как периферийная,

Вмешиваясь в механизм работы УРБД мы должны отдавать себе отчет в том, что если из ПБ сделать узел ПБ (пределать ее в ЦБ, сохранив коды), то в ней будет возможно изменение структуры метаданных и кодов Пб (одна из которых - фактическая ЦБ).
После обмена между двумя центральными ИБ, настройки текущей ЦБ "слетят", она станет ПБ. Поэтому придется вручную сохранять копию таблицы 1SDBSET и после каждого сеанса обмена возвращать на место. С автообменом может случиться неразбериха.
Файл конфигурации цепляется к выгрузке каждый раз при изменении метаданных. Будьте внимательны, не отправьте его случайно на вышестоящий уровень, если изменили в "узле". Файл конфигурации 1Cv7.MD из выгрузки можно удалять (а также принудительно вставлять) вручную, при помощи архиватора ZIP ( см. пример).
Кроме того, для миграции объекта: "Место создания и центр". Дальше "узловой" ИБ данные, введенные на периферии не пройдут и в центр не попадут. Внутри "узла" рекомендуется устанавливать миграцию "все ИБ" (конфигурация "узла" может отличаться от центра).*
Так что. будьте предельно внимательны. Придется частенько "подсовывать" таблицу 1SDBSET перед загрузкой и отслеживать версии конфигурации.

Примечания.
Если число уровней вложенности не превышает 3 (т.е. достаточно перенести через 1 уровень), то вполне можно обойтись указанием дополнительно кода (кода вышестоящей ЦБ) в настройках миграции "место создания и центр".
Конфигурацию (файл 1Cv7.MD) с другими настройками миграции ("все бызы") также можно "подсунуть" вручную перед выгрузкой в вышестоящую ИБ.
В принципе, переносить данные можно не только между непосредственно подчиненными ИБ, но и между двумя любыми ИБ, одна из которых является "узлом" (ЦБ). Для этого необходимо в ИБ "узла" завести ПБ с таким-же кодом, как у ИБ, предназначенной для обмена (см. поля DBSIGN и DBFMODE в 1SDBSET). Для того, чтобы пакет нормально принимался, придется вручную изменить его номер (см. Борьба с изменением МД в УРБД).

Отличия механизмов обмена данными 1С:Предприятия 8 и 1С:Предприятия 7.7

В данном разделе кратко описаны различия в механизмах распределенной информационной базы 1С:Предприятия 8 и компоненты "Управление распределенными информационными базами" 1С:Предприятия 7.7 (УРИБ). Целью раздела не является полный анализ различий двух механизмов, скорее это попытка оказать помощь разработчику, использовавшему 1С:Предприятия 7.7, при построении распределенной информационной базы 1С:Предприятия 8.

В платформе 1С:Предприятие 8 помимо механизма распределенной информационной базы также присутствует универсальный механизм обмена данными. Универсальный механизм обмена данными позволяет производить обмен не только между идентичными конфигурациями, но и конфигурациями, имеющими различную структуру, а также с другими программными системами. Универсальный механизм обмена и механизм распределенной информационной базы основываются на одних и тех же механизмах платформы 1С:Предприятие и представлены в конфигурации объектами метаданных ПланОбмена . Возможно не только одновременное использование обоих механизмом для осуществления обмена данными - для этого используется несколько объектов метаданных ПланОбмена , в которых выбирается используемых механизм и определяется основная логика обмена данными.

Прежде чем сравнивать функциональные возможности двух механизмов стоит отметить, что, в отличие от 1С:Предприятия 7.7 (в котором механизм представлял собой отдельно устанавливаемую компоненту), в платформе 1С:Предприятие 8 механизм распределенной информационной базы является неотъемлемой частью платформы и, вследствие этого, не имеет отдельно ключа аппаратной защиты.

Общие принципы

Общие принципы функционирования механизмов в рассматриваемых версиях платформы 1С:Предприятия похожи и отличны одновременно. Можно сказать, что реализация механизма распределенной информационной базы является не только развитием компоненты "Управление распределенными информационными базами" 1С:Предприятия 7.7, но также представляет собой совершенно иной взгляд на организацию распределенной информационной базы и логику обмена данными внутри нее.

Структура распределенной информационной базы

Структура распределенной информационной базы в версии 7.7 представляла собой двухуровневую иерархию, т.е. имелась четко выделенная центральная информационная база и множество периферийных информационных баз. В платформе 1С:Предприятие 8 структура распределенной информационной базы является многоуровневой иерархией: имеются главные узлы и подчиненные узлы распределенной информационной базы, у которых в свою очередь могут быть собственные подчиненные узлы и т.д. Однако отсутствует понятие "Центральная информационная база" в том виде, в каком оно было в версии 7.7.

В версии 1С:Предприятия 8 можно выделить корневой узел - узел, в котором имеется возможность изменения конфигурации. Все узлы распределенной информационной базы при обмене обладают равными правами. Стоит отметить, что структура распределенной информационной базы (при использовании платформы версии 8) может быть легко изменена, вплоть до изменения корневого узла распределенной информационной базы.

Передача изменений между узлами распределенной информационной базы

Создание узлов распределенной информационной базы

Компонента УРИБ предоставляла единственную возможность создания информационной базы периферийного узла распределенной информационной базы - выгрузка образа новой периферийной информационной базы в файл. В отличие от компоненты УРИБ в платформе версии 8 нет ограничений на способ создания информационной базы, включаемой в состав распределенной информационной базы. Основным требованием является идентичность конфигураций включаемой информационной базы и распределенной информационной базы. Для удобства создания информационной базы нового узла в платформе 1С:Предприятие 8 предусмотрена процедура создания начального образа. Начальный образ может быть создан как в виде файлового варианта информационной базы, так и в виде клиент-серверного варианта.

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

Синхронизация конфигураций

Свойство "Только получатель"

Данного свойства нет в распределенной информационной базе платформы версии 8. Однако поведение аналогичное данному свойству может быть смоделировано при помощи средств встроенного языка.

Участники обмена

Аналогично компоненте УРИБ обмен в платформе 1С:Предприятие 8 осуществляется "пообъектно". Однако в отличие от УРИБ в версии 8 движения документа (являющиеся, по сути, наборами записей различных регистров) мигрируют независимо.

Область миграции

Также в платформе 1С:Предприятие 8 отсутствует понятие "места создания" элемента данных. Данное понятие может быть смоделировано средствами конфигурирования. Например, это может потребоваться для управления миграцией документов, участвующих в последовательностях (подробное описание в статье "Особенности использования последовательности документов в распределенной информационной базе"). Стоит отметить, что если в компоненте УРИБ "место создания" однозначно "привязывало" элемент данных к узлу распределенной ИБ, то в версии 8 реализация привязки элемента данных к узлу по прикладному признаку позволяет выполнять, при необходимости, перенос привязки подобных данных из одного узла распределенной ИБ в другой.

Обмен

Разрешение коллизий

В версии платформы 1С:Предприятие 8 коллизии, возникающие при обмене данными, могут быть разрешены средствами встроенного языка не только в момент регистрации изменений или записи элементов данных (как это было возможно в УРИБ), но и на этапе выгрузки/загрузки измененных данных. Это позволяет достичь гибкости в алгоритмах разрешения коллизий.

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


11 человек в типовой внутренней переговорной совещаются комфортно, снаружи видно,
но практически не слышно.






  • Одна из решаемых на новой территории задач – усиление подготовки ИТ-кадров и взаимодействие фирмы «1С»
    с вузами. В новом здании успешно работают:
      – 22 аудитории, в сумме вмещающие до 520 учащихся, в т.ч. 15 компьютерных классов,
      в которых оборудовано 272 рабочих места.
    • Базовая кафедра факультета инноваций и высоких технологий Московского Физико-Технического Института. Студенты 1-5 курсов самого востребованного факультета одного из сильнейших технических вузов часть обучения проходят в нашем здании.
    • Вскоре сюда переедет и Центр работы с молодыми специалистами 1С, в котором студенты ведущих московских вузов – МГУ, МФТИ, МИФИ, МЭСИ, МАИ, МВТУ, МИИТ, МИЭМ, ВШЭ – не только проходят стажировку
      и дополнительное обучение, но и принимают участие в реальных проектах совместно с разработчиками «1С».






    • Суммарная вместимость переговорных комнат и залов для совещаний в здании превышает 300 мест.
    • При необходимости можно также использовать объединяемые классы учебного центра на 1 и 2 этажах.

    «Умное стекло» позволяет нажатием клавиши сделать стену переговорной прозрачной или наоборот.



    Система перегородок-трансформеров позволяет объединять переговорные
    в большой зал.



    На фото – ресепшен переговорных на первом этаже, нестандартная переговорная
    для создания уютной атмосферы.



    • В условиях, приближенных к реальным, наблюдаем за тем, как люди работают с нашими программами.
    • Две комнаты, разделенные зеркалом Гезелла, прозрачным в одну сторону – как в американских детективах.
    • На левом фото – комната, где работают люди, выполняющие тест, в зеркале отражается задняя часть этой же комнаты.
    • На правом фото – комната, откуда ведется наблюдение.
    • Пишем и потом изучаем:
      • Видео, звук, экран
      • Данные eye tracking – движения глаз



      • На новой территории введена экспериментальная система питания сотрудников.
      • На этажах организованы просторные кофе-пойнты, где для сотрудников созданы условия для перекусов
        и чая-кофе с барными столиками и сидячие места.
      • Установлены бесплатные зерновые кофе-автоматы, кулеры, чайники, кофеварки, микроволновки, холодильники.
      • В рамках соцпакета сотрудники завтракают, обедают и ужинают в специально оборудованной столовой. Разнообразное меню включает обычные, диетические и вегетарианские блюда, горячую выпечку собственного производства, десерты, йогурты, свежевыжатые соки.






      • Для сотрудников предусмотрены специальные зоны отдыха и «места для уединения», в которых можно, например, переговорить по мобильному или обсудить какие-то вопросы с коллегой, не мешая другим сотрудникам.
      • В центральной зоне 7 этажа находится небольшой зимний сад, где можно расслабиться или провести совещание
        в менее формальной обстановке, чем в обычных переговорных.
      • На рабочих этажах установлены турники со шведскими стенками для спортивных разминок.
      • На 7 этаже размещен современный спортзал: новые тренажеры, теннисные столы, раздевалки, душевые, специальные паровые кабины (хамам).
      • По заявкам сотрудников выделена комната с зеркалами для занятий йогой и танцами.
      • Во внутреннем дворе размещены курилки для сотрудников и для студентов учебного центра, в других местах курение не допускается.
















      Что опаснее для здоровья – спорт или курение – точно неизвестно, но есть
      условия и для того,
      и для другого.
      Слева – курилка
      для сотрудников, справа – учебного центра.

      Механизм РИБ — механизм распределенных информационных баз - это когда у вас есть главная база и подчиненная(ые). Главная база может быть только одна, подчиненных может быть много. Каждая подчиненная база может иметь свои подчиненные базы, для которых она будет главной.

      Вот посмотрим на картинку из первой ссылки по запросу в Яндексе:


      РИБ используется для обмена данными. Причем не только теми данными, с которыми работает пользователь, но и данными изменения конфигурации. То есть РИБ позволяет передавать изменения конфигурации. Но изменить конфигурацию можно только в главной базе!

      Визуализируем:

      У нас большая компания и много филиалов. Есть доработанная УНФ, которую мы гордо называем УБФ(Управление Большой Фирмой). Но мы решили, что хватит терпеть то, что все филиалы имеют доступ к документам всех филиалов и каждому филиалу решили сделать отдельную базу, которую синхронизировать с нашей основной базой для передачи данных. Что ж, можно. Сделали.

      И внезапно мы решили изменить картинку, которая появляется при входе в базу, захотели поместить туда логотип нашей фирмы, а почему бы и нет?

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

      А вот если бы мы сделали подчиненные базы для филиалов, то есть использовали РИБ, то и данными бы обменивались, как при обычной синхронизации, и картинка бы сама добавилась во все "базы-дочки". Однако, в конфигуратор зайти бы все-таки пришлось, но только чтобы нажать кнопочку "Обновить конфигурацию базы данных", вот картинка:


      Как создать подчиненную базу, на пальцах:

      я буду использовать Управление торговлей, редакция 11 (11.4.13.275), но способ, в целом, одинаковый во всех типовых конфигурациях.

      1) Сначала проделаем шаги, как при настройке обычной синхронизации:


      2) . поставим галочку, нажмем.



      4) тут ознакомимся с описанием. Я выберу обычную настройку, но если бы мы следовали примеру выше, то нужно было бы выбрать "с фильтром" и там одним кликом выбрать нужный филиал.



      6) Указываем префикс - он будет подставляться к номерам документов, чтобы можно было отличить документы дочки и основной базы.



      7) в общем случае, тут ничего не надо нажимать, кроме "Записать и закрыть".


      8) А вот теперь создаем нашу новую подчиненную базу:


      9) указываем место, куда ее покладем.





      10) Зайдем в нашу новую подчиненную базу и закончим настройки синхронизации(синхронизация уже создалась, так как использовали РИБ, но нужно указать каталог для обмена выбрав "Настройки подключения")


      (обратите внимание на верхний левый угол окна программы, там название базы, он отличается от предыдущих, так как это "дочка")

      Кстати, в новой базе все пользователи будут выключены, пароли сброшены, нужно включить руками:


      В общем-то ВСЕ.

      Подчиненная база создана!

      Теперь, когда наши программисты что-нибудь улучшат, эти улучшения прилетят в подчиненные базы сами.

      Вот что-то изменили в основной базе:


      нам нужно перенести изменения в базы-дочки.

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


      После того, как синхронизация закончится, заходим в базу дочку и так же жмем "Синхронизировать", база загрузит данные и напишет:



      После нажатия на Далее база закроется и начнет устанавливать обновления.


      Когда обновы установятся, база начнет запускаться и сообщит нам следующее:


      Это означает, что не обновлена конфигурация базы данных. Та самая маленькая кнопка в конфигураторе и это именно та причина, почему придется ОДИН раз зайти в конфигуратор. Что ж, зайдем в конфигуратор базы-дочки и нажмем эту кнопку, заодно вообще посмотрим что-да-как там, мы ж там еще не были.

      Откроем конфигурацию и вот что увидим


      Нажмем на "Обновить конфигурацию базы данных".

      Увидим список изменений, которые прилетели с обновлениями:


      И вот эти обновления появились в подчиненной базе.


      Теперь необходимо запустить базу в пользовательском режиме, чтобы выполнились обработчики обновления.

      Несколько правил:

      1) Все узлы, кроме одного, должны иметь по одному главному узлу и один узел не будет иметь главного узла - это корневой узел.

      2) Конфигурация может быть изменена только в узле, не имеющем главного узла (то есть в корневом).

      3) Изменения конфигурации будут передаваться от главного к подчиненным узлам.

      4) Разрешение коллизий так же будет производиться исходя из отношений "главный - подчиненный" - если изменения сделаны одновременно и в главном и в подчиненном узлах, то приняты будут изменения главного узла.

      5) Сделать подчиненный узел в распределенной базе можно разными способами, но создание начального образа является рекомендуемым.

      А теперь то, ради чего все писалось.

      Как подчиненную базу сделать обычной(нормальной, отдельной, как хотите).

      Я опишу только тот способ, которым пользуюсь. Это моя шпаргалка. Но он не единственный.

      1) Заходим в свойства ярлыка запуска окна 1С:Предприятие:


      2) В поле "Объект" дописываем:

      DESIGNER /F"Путь до базы" /N"Имя Пользователя в базе" /P"Пароль пользователя" /ResetMasterNode


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

      Каждый из них содержит свой кусок паззла от полноценной картины: Легкое управление списками баз 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\

      Читайте также: