Comments 33
Главное откровение (или нюанс) тут в том, что список баз подключается не по пользователю, а к ПК. К сожалению, пользователь не может с своими правами заменить файл конфигурации, находящийся в C:\ProgramData\1C\1CEStart\ и за него это сделает ПК.
Не понял. Допустим, сам пользователь руками не может, но GPO preferences по умолчанию отрабатывают под системной учетной записью, даже если применяется политика «для пользователя» (для использования контекста безопасности пользователя надо специально настройку включать).
Что бы это делали только ПК с установленной 1С, задаем условия выполнения групповой политики через Item Level Targeting.
Если вы даже для сетевых шар придерживатесь политики «отсекать доступ на самом верхнем уровне» и даже сделали отдельный GPO для разлития файлика, то необходимые проверки было бы логично делать фильтром WMI, а не внутри самой политики. ;)
Системная учетная запись («SYSTEM») не может в сеть. Поэтому она ничего не заменит, посколько не доберется до файла лежащего в сети.
Пользователь же не может заменить локальный файл из-за недостатка прав. Как вариант — сначала менять разрешения на файл, потом в контексте пользователя его копировать, но это уже один лишний шаг. Плюс, скажем на терминальном сервере появляется возможность злоупотребления путем редактирования списка баз. Редактирует один — страдают все.
Фильтрация на вкус и цвет. Я же говорю, что важна сама концепция. Нравится WMI, используйте!
Пользователь же не может заменить локальный файл из-за недостатка прав. Как вариант — сначала менять разрешения на файл, потом в контексте пользователя его копировать, но это уже один лишний шаг. Плюс, скажем на терминальном сервере появляется возможность злоупотребления путем редактирования списка баз. Редактирует один — страдают все.
Фильтрация на вкус и цвет. Я же говорю, что важна сама концепция. Нравится WMI, используйте!
И ведь правы, пока все самое вкусное едят сидишь и настраиваешь базы… начал по вашему мануалу внедрять у себя. Спасибо!!!
Где вы были неделю назад?! Не пришлось бы писать скрипт.
Главным откровением для меня стало то, что 1cestart.exe молча, не выводя никаких ошибок, игнорирует v8i файлы к которым не может получить доступ. Ключевая особенность решения я думаю.
PS: а все знают, что %appdata%\1C\1CEStart\1CEStart.cfg имеет кодировку Unicode, а %appdata%\1C\1CEStart\ibases.v8i кодировку utf8? По крайней мере сама 1С их так создаёт.
Главным откровением для меня стало то, что 1cestart.exe молча, не выводя никаких ошибок, игнорирует v8i файлы к которым не может получить доступ. Ключевая особенность решения я думаю.
PS: а все знают, что %appdata%\1C\1CEStart\1CEStart.cfg имеет кодировку Unicode, а %appdata%\1C\1CEStart\ibases.v8i кодировку utf8? По крайней мере сама 1С их так создаёт.
зачем вы трогаете системные файлы， когда можно трогать %AppData%\1C\1CEStart\1CEStart.cfg
Обращаю внимание， чтобы данный файл заработал， нужно чтобы ibases.v8i существовали (хоть пустые)
Обращаю внимание， чтобы данный файл заработал， нужно чтобы ibases.v8i существовали (хоть пустые)
Да. Все верно. Вариант с изменением файла в профиле пользователя проще в реализации и логичнее применить его. Правда практика использования показала, что несмотря на то, что все выглядит логически просто, на практике первый запуск 1С слишком часто показывает отсутствие баз. Несмотря на наличие политики с ILT на создание файла ibases.v8i в случае его отсутствия.
Терминальным пользователям с автостартом 1Ски отсутствие баз очень не понравилось, что привело к лишнему количеству заявок в Service Desk.
С VDI не пробывал, но боюсь там эта беда будет помноженной на х100
На семинарах Microsoft, на вопросы почему на ровном месте не отрабатывают групповые политики инженеры говорят, что все мои беды решит SC и позволит мне проконтролировать все нужные настройки. Троллят.
Терминальным пользователям с автостартом 1Ски отсутствие баз очень не понравилось, что привело к лишнему количеству заявок в Service Desk.
С VDI не пробывал, но боюсь там эта беда будет помноженной на х100
На семинарах Microsoft, на вопросы почему на ровном месте не отрабатывают групповые политики инженеры говорят, что все мои беды решит SC и позволит мне проконтролировать все нужные настройки. Троллят.
Вообще идея состоит в том, что 1С нужно знать только удалённый файлик .cfg в удалённом каталоге, а дальше всё понимается 1С кой на уровне прав доступа AD к файлам конфигурации.
Глупо прописывть одну и ту же строчку каждому пользователя. А так вы делаете ссылку, смотреть там — всё…
Если сеть из нескольких распределённых офисов и серверов 1С, то оптимальный путь до конфигурационной шары меняется только с переездом компьютера. Вообще на клиентском компьютере больше ничего не нужно делать в плане конфигурационных файлов списков баз.
Глупо прописывть одну и ту же строчку каждому пользователя. А так вы делаете ссылку, смотреть там — всё…
Если сеть из нескольких распределённых офисов и серверов 1С, то оптимальный путь до конфигурационной шары меняется только с переездом компьютера. Вообще на клиентском компьютере больше ничего не нужно делать в плане конфигурационных файлов списков баз.
Возможно не совсем уловил суть вопроса :)
В статье указывается DFS путь до файлов конфигурации. Он решает сразу и вопросы филиалов и мультидоменной сети. Список баз постоянно меняется (в моём случае), как следствие на ПК должен располагаться актуальный список. Переезд компьютера — наименьшая из проблем. Возможность подключать базы организации находящейся в одном домене бухгалтерам или аудиторам из другого, опять же в моём случае очень частое явление. Таргетинг при этом решает проблему (т.е. не дает), когда человек пытается открыть базу находящуюся не в его локации не через терминал или v-app.
В статье указывается DFS путь до файлов конфигурации. Он решает сразу и вопросы филиалов и мультидоменной сети. Список баз постоянно меняется (в моём случае), как следствие на ПК должен располагаться актуальный список. Переезд компьютера — наименьшая из проблем. Возможность подключать базы организации находящейся в одном домене бухгалтерам или аудиторам из другого, опять же в моём случае очень частое явление. Таргетинг при этом решает проблему (т.е. не дает), когда человек пытается открыть базу находящуюся не в его локации не через терминал или v-app.
К сути статьи не имеет отношения. Но мои глаза начали кровоточить когда я увидел скрин из AD.
Имена на кирилице, с пробелами, с нижним подчеркиванием в качестве первого символа.
Очень в стиле 1С, но в остальном мире ИТ это моветон.
Имена на кирилице, с пробелами, с нижним подчеркиванием в качестве первого символа.
Очень в стиле 1С, но в остальном мире ИТ это моветон.
Когда то и я писал названия групп на английском :) у меня был один домен, и я там был единственный сисадмин.
Сейчас почти вся структура на русском. Я даже объясню почему:
— Проблем с совместимостью нет. Давно. Все программы поддерживают работу русскими именами в AD. nix системы в том числе.
— Поддержка стуктуры AD в соответствии с штатным расписанием каждой организации не вызывает проблем.
— Сверка выгруженной штатки из учетной системы для полуавтоматического сравнения с структурой AD не составляет проблем. (Должности, подразделения и т.д.) как следствие нет проблем с актуализацией данных в AD.
— Структура, назначение групп интуитивно понятны тем у кого с английским не очень хорошо (например — аккаунт админам).
— Нет проблем с взаимопониманием для чего и куда в большой (4+ чел) и распределенной команде сисадминов. Я не трачу время на объяснение очевидных вещей новичкам. Сторонние команды ИТ спецов (например — техподдержка) не испытывают проблем при диагностике неполадок на устройствах пользователей (пресловутый gpresult /h 11111.htm)
— Имена групп, как правило, начинаются на "_" (подвал), это очень облегчает быструю выборку среди объектов AD в поиске без тыканья лишних галочек что искать нужно только среди групп. Это видно на примере скриншота в моей статье, где происходит выбор группы AD для назначения доступа к файлам v8i. Набрал "_Ба" — получил все группы с списками баз. Набрал "_До" получил все группы выдающие доступ. И так далее.
Резюмируя: вся структура AD выстроена так, что бы быть логичной и интуитивно понятной, обеспечивающей быстрый поиск и управление объектами. А объектов AD под управлением моей группы очень много :)
Четко построенная, логичная, быстрая работа это моветон в мире ИТ? Сомневаюсь.
У Вас это пока привычка, дань моде… у меня же — функциональный порядок, проверенные временем и шквалом заявок, условия эффективной работы.
Без обид, я делюсь ценным опытом.
Сейчас почти вся структура на русском. Я даже объясню почему:
— Проблем с совместимостью нет. Давно. Все программы поддерживают работу русскими именами в AD. nix системы в том числе.
— Поддержка стуктуры AD в соответствии с штатным расписанием каждой организации не вызывает проблем.
— Сверка выгруженной штатки из учетной системы для полуавтоматического сравнения с структурой AD не составляет проблем. (Должности, подразделения и т.д.) как следствие нет проблем с актуализацией данных в AD.
— Структура, назначение групп интуитивно понятны тем у кого с английским не очень хорошо (например — аккаунт админам).
— Нет проблем с взаимопониманием для чего и куда в большой (4+ чел) и распределенной команде сисадминов. Я не трачу время на объяснение очевидных вещей новичкам. Сторонние команды ИТ спецов (например — техподдержка) не испытывают проблем при диагностике неполадок на устройствах пользователей (пресловутый gpresult /h 11111.htm)
— Имена групп, как правило, начинаются на "_" (подвал), это очень облегчает быструю выборку среди объектов AD в поиске без тыканья лишних галочек что искать нужно только среди групп. Это видно на примере скриншота в моей статье, где происходит выбор группы AD для назначения доступа к файлам v8i. Набрал "_Ба" — получил все группы с списками баз. Набрал "_До" получил все группы выдающие доступ. И так далее.
Резюмируя: вся структура AD выстроена так, что бы быть логичной и интуитивно понятной, обеспечивающей быстрый поиск и управление объектами. А объектов AD под управлением моей группы очень много :)
Четко построенная, логичная, быстрая работа это моветон в мире ИТ? Сомневаюсь.
У Вас это пока привычка, дань моде… у меня же — функциональный порядок, проверенные временем и шквалом заявок, условия эффективной работы.
Без обид, я делюсь ценным опытом.
Не могу с вами согласится.
Для описания есть поле описание.
Написание на английском, причем с использованием минимального насколько это возможно без потери смысла, количества символов это общепринятая практика. Польза как минимум в том, что вам не нужно менять раскладку во время составления скрипта. А если мыслить чуть шире, то рано или поздно плоды вашей работы могут попасть к человеку не знакомому с кириллицей вообще.
Вы тратите 9 символов, только на то чтобы сказать, что это база 1с. Сами же потом приводите пример. По факту вы ищете по 3 символам. А если бы избавились от нижнего подчеркивания, хватило бы и двух.
Дальше у вас длинное описание базы на русском, а в скобках на английском. Зачем? Эта информация дублируется в описание.
db_venus_ut — дает полное представление о том, что это и зачем. Также легко ищется по первым двум знакам. Если когда-нибудь потребуется писать скрипты и обрабатывать вывод, преимущество монолитных английских имен будет очевидно перед 40 символьным русско-английским с пробелами.
Вы приводите еще пример не владеющих английским… Это мне крыть нечем.)
ЗЫ. Тоже надеюсь не сказал обидного ничего. Метафора про глаза, исключительно из личного опыта. Потому что мне приходилось в процессе автоматизации парсить вывод системы настроенной в похожем ключе. И я все не мог понять… ну зачем. Ведь можно просто обрезать 90% имени и нисколько не потерять в информативности.
Для описания есть поле описание.
Написание на английском, причем с использованием минимального насколько это возможно без потери смысла, количества символов это общепринятая практика. Польза как минимум в том, что вам не нужно менять раскладку во время составления скрипта. А если мыслить чуть шире, то рано или поздно плоды вашей работы могут попасть к человеку не знакомому с кириллицей вообще.
Вы тратите 9 символов, только на то чтобы сказать, что это база 1с. Сами же потом приводите пример. По факту вы ищете по 3 символам. А если бы избавились от нижнего подчеркивания, хватило бы и двух.
Дальше у вас длинное описание базы на русском, а в скобках на английском. Зачем? Эта информация дублируется в описание.
db_venus_ut — дает полное представление о том, что это и зачем. Также легко ищется по первым двум знакам. Если когда-нибудь потребуется писать скрипты и обрабатывать вывод, преимущество монолитных английских имен будет очевидно перед 40 символьным русско-английским с пробелами.
Вы приводите еще пример не владеющих английским… Это мне крыть нечем.)
ЗЫ. Тоже надеюсь не сказал обидного ничего. Метафора про глаза, исключительно из личного опыта. Потому что мне приходилось в процессе автоматизации парсить вывод системы настроенной в похожем ключе. И я все не мог понять… ну зачем. Ведь можно просто обрезать 90% имени и нисколько не потерять в информативности.
Аргументированные доводы это всегда хорошо! :)
Я не работаю в мультинациональной трансатлантической корпорации, где английский является рабочим языком. Зато русскоговорящих вокруг — каждый первый. Когда это случится перейду на новые стандарты, мне не сложно.
Насчет скриптов, есть только один недостаток — они становятся в некоторых случаях просто монструозными на вид, хотя на их функционал это не влияет. Переключение раскладки при слепом методе печати — просто две дополнительные кнопки. Я за это время даже руку с клавиатуры на мышку переместить не успею :)
Что до людей не знакомых с кириллицей: я же умудряюсь разобраться в примерах решения на PowerShell, скажем, с итальянских или немецких форумов, хотя этими языками не владею.
… или поставить "_" перед именем и гарантированно получить выборку по группам. Каждый решает сам :)
Я повторюсь. Пока я был один в своей инфраструктуре, я все знал досконально. Сейчас у меня если специалист закрепленный за группой обслуживаемых организаций уходит в отпуск, то я без проблем могу его заменить другим специалистом, или раздать его заявки на нескольких человек. При этом никому не нужно искать документацию, таблицы соответствий и прочие вещи, напрягать звонками отдыхающего человека что бы понять, где что находится. Все сразу в AD, на виду, на понятном языке не допускающим двойных толкования и неточностей перевода. Работа продолжается в штатном режиме.
Я не работаю в мультинациональной трансатлантической корпорации, где английский является рабочим языком. Зато русскоговорящих вокруг — каждый первый. Когда это случится перейду на новые стандарты, мне не сложно.
Насчет скриптов, есть только один недостаток — они становятся в некоторых случаях просто монструозными на вид, хотя на их функционал это не влияет. Переключение раскладки при слепом методе печати — просто две дополнительные кнопки. Я за это время даже руку с клавиатуры на мышку переместить не успею :)
Что до людей не знакомых с кириллицей: я же умудряюсь разобраться в примерах решения на PowerShell, скажем, с итальянских или немецких форумов, хотя этими языками не владею.
Вы тратите 9 символов, только на то чтобы сказать, что это база 1с. Сами же потом приводите пример. По факту вы ищете по 3 символам. А если бы избавились от нижнего подчеркивания, хватило бы и двух.Опять вопрос методики по быстрой работе: при выборе объекта зайти в Object Types, выбрать нужный вид и применить область действия. Минимум три дополнительных клика.
… или поставить "_" перед именем и гарантированно получить выборку по группам. Каждый решает сам :)
Дальше у вас длинное описание базы на русском, а в скобках на английском. Зачем?Читаемость, понятность. Имя на русском это то как группу запрашивают пользователи. В скобках имя базы к кластере 1С/сервере баз данных. Оно обычно озвучивается уже 1Сниками для исключения путаницы баз. Проблем с восприятием и пониманием у ИТ специалистов нет.
Эта информация дублируется в описание.Ну в описании как раз идет отсылка на используемый кластер и сервер баз данных. Не вижу там дубляжа.
db_venus_ut — дает полное представление о том, что это и зачем.Я почти согласен. Но вернемся к реалиям. Есть базы new2_baza2_copy и new2_baza2. С ними то мне что делать? Они рабочие и имена их я поменять не могу, вернее могу, но все сломается :) А описание к базе доступно не везде при выборе групп AD. Сейчас у меня таких «наследных» баз более 60+. Добавлять еще один англоязычный алиас? Это нужно документировать, поддерживать, тратить время. А зачем это документировать, если можно в AD разместить актуальную информацию и по необходимости генерировать отчеты напрямую с AD?
Я повторюсь. Пока я был один в своей инфраструктуре, я все знал досконально. Сейчас у меня если специалист закрепленный за группой обслуживаемых организаций уходит в отпуск, то я без проблем могу его заменить другим специалистом, или раздать его заявки на нескольких человек. При этом никому не нужно искать документацию, таблицы соответствий и прочие вещи, напрягать звонками отдыхающего человека что бы понять, где что находится. Все сразу в AD, на виду, на понятном языке не допускающим двойных толкования и неточностей перевода. Работа продолжается в штатном режиме.
В вашем конкретном случае это работает и не создает проблем.
Хороший пример new2_baza2_copy. Человек который это придумал не видел перспективы. Для него это работало. Но вам теперь нужны комментарии, чтобы понять о чем идет речь.
Насчет групп и нижнего подчеркивания. Db вполне достаточно для поиска, выбирать поиск только по группам нет необходимости. В худщем случае, вы получите пару лишних пользователей, если например у вас есть кто-то с фамилией начинающейся на 'дб', и то они будут в конце списка.
И насчет восприятия тоже очень спорно. Мозг прекрасно понимает сокращения русских слов даже на латинице.
Это все конечно же оффтоп, которому место в отдельной статье о именованиях.
Хороший пример new2_baza2_copy. Человек который это придумал не видел перспективы. Для него это работало. Но вам теперь нужны комментарии, чтобы понять о чем идет речь.
Насчет групп и нижнего подчеркивания. Db вполне достаточно для поиска, выбирать поиск только по группам нет необходимости. В худщем случае, вы получите пару лишних пользователей, если например у вас есть кто-то с фамилией начинающейся на 'дб', и то они будут в конце списка.
И насчет восприятия тоже очень спорно. Мозг прекрасно понимает сокращения русских слов даже на латинице.
Это все конечно же оффтоп, которому место в отдельной статье о именованиях.
Хороший пример new2_baza2_copy. Человек который это придумал не видел перспективы. Для него это работало. Но вам теперь нужны комментарии, чтобы понять о чем идет речь.Баз много, 1Сников много. 1Сников я проконтролировать не могу, а вот своих подчиненных — да.
Db вполне достаточно для поискаВяло тянет на общемировую практику, но фактически мы говорим об одном и том же — метка для группы с базой данных. Каждый реализует её как хочет. На вкус и цвет :)
Для Windows XP необходимо указывать: %ALLUSERSPROFILE%\Application Data\1C\1CEStart\1CEStart.cfg
Ибо переменная %ProgramData% появилась только в Vista.
Проверено опытным путём.
Ибо переменная %ProgramData% появилась только в Vista.
Проверено опытным путём.
Я чуть-чуть слоупок(Избранное — зло), но не увидел ни у автора, ни в комментах одной маленькой рекомендации
Если вы вручную создаёте v8i-файлы — проверьте, чтоб в файлах не совпадали ID у разных баз. Это может вызывать очень странные коллизии. Какие — не помню, однажды убил почти час, пока не нашел причину проблемы, с тех пор просто взял за правило поменять пару символов в ID как минимум при копипасте внутри v8i.
Если вы вручную создаёте v8i-файлы — проверьте, чтоб в файлах не совпадали ID у разных баз. Это может вызывать очень странные коллизии. Какие — не помню, однажды убил почти час, пока не нашел причину проблемы, с тех пор просто взял за правило поменять пару символов в ID как минимум при копипасте внутри v8i.
Невнятные названия баз! — в этом месте, я каждый раз представляю, как своими руками душу очередного 1Сника за базу с именем «new2_baza2_copy» к которой привязана куча обработок
Мы эту проблему решили кардинально — 1С ник не может сам создавать базы. Только через заявку системному администратору. А уж тот с него вытрясет для чего и зачем база нужна. Либо не даст базу.
Периодически тот же системный администратор делает инвентаризации и в случае обнаружения «левых» баз их удаляет, предварительно уведомив 1С-ников.
С новыми все нормально, вопрос больше про наследные базы.
Глупо вешать всё на админа, когда можно настоить и передать 1С'нику. Суровые реалии нашего рынка диктуют другие условия.
1С разработчик, он же по совместительству и админ 1С, он контролирует заведение пользователей в 1С, он принимает решение об переносе функционала в отдельную базу, конфигурацию. И нужно лишь ему немножко помочь, чтобы он в очередной раз не мучил тебя просьбой подключить кому-то каую-то базу, а потом её отключить… или поменять настройки подключения к базе… Эта кухня не нужна админу… И во многих организациях, даже ооочень крупных, админы почти не занимаются администрированием 1С. Это я взял не из головы, а практика, которую я вижу.
А к вашим словам, что 1С'ник не может создать базу своими руками… Он очень легко может наколхозить под пользователем сотрудника, придя за компьютер… И вот тут, вы пятнадцать раз пожалеете, что не научили этого колхозника работать со списком баз правильно, и не дали его в руки инструпент для правильной работы. Это тоже личный опыт. Потому что он сначала навертит, а потом, когда неполучится, придёт к вам, и вы будете всё это говно разгребать, как админ всия компании!
Про инвентаризации… Если у вас есть настолько дешёвые ресурсы админа, что ему больше заняться не чем, как инвентаризировать срач плодящийся регулярно, то пожалуйста. Или у вас текуча бешенная среди админов, которым приходится, регулярно лазить и раскапывать эту фигню, связываться с 1С'никами и вызнвать, какая тут хрень для чего нужна, в то время, когда этим ребятам нужно спешить, и некогда учиться летать, поэтому документации даже своей служебной они не пишут. Это тоже личный опыт.
1С разработчик, он же по совместительству и админ 1С, он контролирует заведение пользователей в 1С, он принимает решение об переносе функционала в отдельную базу, конфигурацию. И нужно лишь ему немножко помочь, чтобы он в очередной раз не мучил тебя просьбой подключить кому-то каую-то базу, а потом её отключить… или поменять настройки подключения к базе… Эта кухня не нужна админу… И во многих организациях, даже ооочень крупных, админы почти не занимаются администрированием 1С. Это я взял не из головы, а практика, которую я вижу.
А к вашим словам, что 1С'ник не может создать базу своими руками… Он очень легко может наколхозить под пользователем сотрудника, придя за компьютер… И вот тут, вы пятнадцать раз пожалеете, что не научили этого колхозника работать со списком баз правильно, и не дали его в руки инструпент для правильной работы. Это тоже личный опыт. Потому что он сначала навертит, а потом, когда неполучится, придёт к вам, и вы будете всё это говно разгребать, как админ всия компании!
Про инвентаризации… Если у вас есть настолько дешёвые ресурсы админа, что ему больше заняться не чем, как инвентаризировать срач плодящийся регулярно, то пожалуйста. Или у вас текуча бешенная среди админов, которым приходится, регулярно лазить и раскапывать эту фигню, связываться с 1С'никами и вызнвать, какая тут хрень для чего нужна, в то время, когда этим ребятам нужно спешить, и некогда учиться летать, поэтому документации даже своей служебной они не пишут. Это тоже личный опыт.
Ну реалии я как вижу у всех разные.
У нас вся работа построена через сервисдеск, никто никого не мучает. Указанная в статье структура работы для нашего случая оптимальна. Все стандартизировано, и понятно даже новичкам как от админов, так и от 1Сников. Заявка пришла, её отработали.
У нас не ходят ножками за ПК пользователей, ибо они раскиданы по области, а наш активно растущий офис в обособленном здании :) а еще их (1Сников) у нас сильно больше одного, не говоря о том, что моя группа работает и с 1Сниками многих, а не только нашей, организаций.
Инвентаризационные циклы в обслуживаемых организациях мы всеравно проводим, и в них входят не только базы 1С: админы свое перепроверяют, 1Сники своё, техподдержка своё. Это нормальный циклический процесс в рамках работы аутсорсера.
У нас вся работа построена через сервисдеск, никто никого не мучает. Указанная в статье структура работы для нашего случая оптимальна. Все стандартизировано, и понятно даже новичкам как от админов, так и от 1Сников. Заявка пришла, её отработали.
У нас не ходят ножками за ПК пользователей, ибо они раскиданы по области, а наш активно растущий офис в обособленном здании :) а еще их (1Сников) у нас сильно больше одного, не говоря о том, что моя группа работает и с 1Сниками многих, а не только нашей, организаций.
Инвентаризационные циклы в обслуживаемых организациях мы всеравно проводим, и в них входят не только базы 1С: админы свое перепроверяют, 1Сники своё, техподдержка своё. Это нормальный циклический процесс в рамках работы аутсорсера.
Прекрасная аккумуляция накопленного знания! Это я об этой статье.
Мой личный опыт привёл меня к мысли о наименьшем завязывании на групповые политики. Факт остаётся в том, что они очень медленные по скорости реакции на событие и распихивать ими действительно можно только ссылочки на файлик конфигурации на уровне всей клиентской машины для всех пользователей.
Эта статья о полном захвате власти над управлением списком баз 1С админом. В AD вы не пустите 1С разработчика, и не будете его обучать, как ей пользоваться… А лопатить всё самому за них — права, не стоит.
Я сделал всё проще. Я так же разграничил доступ к файлам на уровне парав пользователей AD в файловой системе, и совершенно не засирал AD лишней информацией о группах, базах и прочей хрени. Просто даёте права правки изменения на каталог с конфигурационными файлами 1С разработчику или группе этих оболтусов, обучаете основному принципу, как это работает, и забываете об этом, как о страшном сне.
Так нужно сделать по уже описанным выше комментариям… 1С разработчик, в большинстве компаний — он же и админ 1С баз, серверов, техподдержка пользователей в части 1С…
Вот единственный ключевой момент о котором стоит позаботиться сразу, так, это ссылка на шару с конфигурационными файлами на клиента обязательно должна быть ссылкой в dns на реальный адерс. И тогда, вам вообще не нужно будет использовать GPO для изменения ссылки на конфигурационную шару. Всё правление перемещается в DNS. Если вы, вдруг вздумаете перенести шару на другой сервер, то вам всего лишь достаточно поменять DNS запись синонима. Это прорывная идея, я вам скажу, которой я очень горжусь.
Вообще хотел обновление своей статьи сделать, часть 2 — так сказать. Но времени нет вырисовывать всё это. Поэтому решил отписаться самым ядром идеи здесь в комментарии.
Поверьте не стоит засирать AD этим мусором, который вы не разгребёте с увеличивающимся количеством пользователей, баз, 1С разработчиков, кластеров. Просто отдайте эту кухню им и скажите, что у них есть все возможности для манипуляции с доступом к базам. Это куда продуктивней. А ваша работа должна сводиться к следующим моментам:
— Создать конфигурационную шару,
— набить конфигурационными файлам,
— раздать права ответственным,
— на все компьютеры клиентские в общепользовательский каталог напихать ссылку на ссылку в DNS на запись о конфигурационной шаре.
— обучить «этих бездельников» работать с этим.
Единственная работа которая вас ждёт в дальнейшем с этим, это перенос конфигурационной шары на другой сервер. Тогда, вам, прямо, предстоит титанический труд:
— скопировать шару с правами, как есть,
— изиминить ссылку на шару в DNS.
Вот это будет дичайшая автоматизация процесса. Это с позиции Админа.
С позиции 1С разработчика, тоже всё удобно, они сами рулят тем, чем рулили, только в более полной мере, и им не нужно повышать права в системе хоть на сколько нибудь.
P.S. «Бездельники» взяты в кавычки… Не нужно подымать рёв. Я не считаю 1С разработчиков бездельниками… Может, лентяями, но не бездельниками. Об их тяжёлом труде я знаю не по наслышке — сам сейчас работаю 1С программистом.
Мой личный опыт привёл меня к мысли о наименьшем завязывании на групповые политики. Факт остаётся в том, что они очень медленные по скорости реакции на событие и распихивать ими действительно можно только ссылочки на файлик конфигурации на уровне всей клиентской машины для всех пользователей.
Эта статья о полном захвате власти над управлением списком баз 1С админом. В AD вы не пустите 1С разработчика, и не будете его обучать, как ей пользоваться… А лопатить всё самому за них — права, не стоит.
Я сделал всё проще. Я так же разграничил доступ к файлам на уровне парав пользователей AD в файловой системе, и совершенно не засирал AD лишней информацией о группах, базах и прочей хрени. Просто даёте права правки изменения на каталог с конфигурационными файлами 1С разработчику или группе этих оболтусов, обучаете основному принципу, как это работает, и забываете об этом, как о страшном сне.
Так нужно сделать по уже описанным выше комментариям… 1С разработчик, в большинстве компаний — он же и админ 1С баз, серверов, техподдержка пользователей в части 1С…
Вот единственный ключевой момент о котором стоит позаботиться сразу, так, это ссылка на шару с конфигурационными файлами на клиента обязательно должна быть ссылкой в dns на реальный адерс. И тогда, вам вообще не нужно будет использовать GPO для изменения ссылки на конфигурационную шару. Всё правление перемещается в DNS. Если вы, вдруг вздумаете перенести шару на другой сервер, то вам всего лишь достаточно поменять DNS запись синонима. Это прорывная идея, я вам скажу, которой я очень горжусь.
Вообще хотел обновление своей статьи сделать, часть 2 — так сказать. Но времени нет вырисовывать всё это. Поэтому решил отписаться самым ядром идеи здесь в комментарии.
Поверьте не стоит засирать AD этим мусором, который вы не разгребёте с увеличивающимся количеством пользователей, баз, 1С разработчиков, кластеров. Просто отдайте эту кухню им и скажите, что у них есть все возможности для манипуляции с доступом к базам. Это куда продуктивней. А ваша работа должна сводиться к следующим моментам:
— Создать конфигурационную шару,
— набить конфигурационными файлам,
— раздать права ответственным,
— на все компьютеры клиентские в общепользовательский каталог напихать ссылку на ссылку в DNS на запись о конфигурационной шаре.
— обучить «этих бездельников» работать с этим.
Единственная работа которая вас ждёт в дальнейшем с этим, это перенос конфигурационной шары на другой сервер. Тогда, вам, прямо, предстоит титанический труд:
— скопировать шару с правами, как есть,
— изиминить ссылку на шару в DNS.
Вот это будет дичайшая автоматизация процесса. Это с позиции Админа.
С позиции 1С разработчика, тоже всё удобно, они сами рулят тем, чем рулили, только в более полной мере, и им не нужно повышать права в системе хоть на сколько нибудь.
P.S. «Бездельники» взяты в кавычки… Не нужно подымать рёв. Я не считаю 1С разработчиков бездельниками… Может, лентяями, но не бездельниками. Об их тяжёлом труде я знаю не по наслышке — сам сейчас работаю 1С программистом.
Ох.
Пока что, схема работы описанная в статье, остается актуальной и самой простой на данный момент. Если кто ткнет меня в статью описывающую более удобный механизм работы для аутсорсера, я был бы только рад.
1С разработчик, в большинстве компаний — он же и админ 1С баз, серверов, техподдержка пользователей в части 1С…У нас, 1Сники (аромя прогерства и методической работы) отвечают только за работоспособность серверной части 1С и СЛК к ней. Админы рулят всем остальным. Имхо, это оптимальный для всех подход.
Всё правление перемещается в DNS. Если вы, вдруг вздумаете перенести шару на другой сервер, то вам всего лишь достаточно поменять DNS запись синонима. Это прорывная идея, я вам скажу, которой я очень горжусь.Полагаю разговор идет о CNAME-записи. На мой взгляд DFS куда практичнее.
Вообще хотел обновление своей статьи сделать, часть 2 — так сказать. Но времени нет вырисовывать всё это. Поэтому решил отписаться самым ядром идеи здесь в комментарии.Я бы с интересом почитал статью, реальный опыт и оптимальные решения всегда интересны.
Поверьте не стоит засирать AD этим мусором, который вы не разгребёте с увеличивающимся количеством пользователей, баз, 1С разработчиков, кластеров.Зря Вы так. AD для того и создано. Я всегда вижу какому пользователю какая база подключена. Очень удобно при аудитах прав доступа.
Просто отдайте эту кухню им и скажите, что у них есть все возможности для манипуляции с доступом к базам.А они сами не хотят брать. Они хотят прогать, а не настраивать разрешения в папках. И я с ними согласен, не их это.
— на все компьютеры клиентские в общепользовательский каталог напихать ссылку на ссылку в DNS на запись о конфигурационной шаре.вот тут бы подробностей побольше.
скопировать шару с правами, как естьмне несложно добавить, ключ /SEC в команду для robocopy.exe
Вот это будет дичайшая автоматизация процесса. Это с позиции Админа.Вы просто переложили свою задачу на чужие плечи.
Пока что, схема работы описанная в статье, остается актуальной и самой простой на данный момент. Если кто ткнет меня в статью описывающую более удобный механизм работы для аутсорсера, я был бы только рад.
О первым же замечаниям вижу, что у вас порядок в компании, все на своих местах.
И это ещё одна технология с которой предстоит разобраться человеку, хотя польза в ней сомнительна… Это моя личное мнение. Вполне возможно, что я ошибаюсь.
На пользователях по пути "%ProgramData%\1C\1CEStart\1CEStart.cfg" в довесок к тому что там имеется по умолчанию кладёте вот такую вот строчку:
В файле, на который мы ссылаемся выше (\\server.exemple.ru\СпискиБаз\1CEStart.cfg) пишем ссылки на наши базы:
В этом файле (\\server.exemple.ru\СпискиБаз\1CEStart.cfg) путь можно указывать относительно его местоположения, поэтому я сэкономил время и байты памяти, чтобы не калякать весь полный путь. Синтаксис файлов *.v8i, думаю вам не стоит разъяснять.
Каждый такой файл *.v8i содержит в себе информацию об одной базе. Это идея такая. Я заню, что туда можно написать сколь угодно баз. Но моя идея в том, чтобы одна база — один файл. Тогда если разработчику или админу нужно поменять настройки подключения к базе, то он правит только этот файл один раз, и всё! После этого после перезапуска клиента люди будут цепляться по новым параметрам. И самое важно, чтобы эти базы не плодились копиями по филиалам. Т.е. Есть кластер 1С, рдом с ним в одной сети находится конфигурационная шара с такими файликами, декларирующая подключение к базам 1С этого кластер. И если у нас появились пользователи с удалённого офиса, где-нибудь в запедрыщинске, то мы им им по первому пункту этого разяснения в общепользовательский каталог пихаме запись на эту шару (у него таких шар может быть записана хоть тыща). И он также автоматом узнаёт об этой базе, если у него есть права на чтение этой конфигурационной шары и файликов. Вот такой не сложны принцип самоорганизации. И у вас появляется распределенная система конфигурационных файлов, ответственных над которыми вы ставите по регионам, т.к. они будут сами там реорганизовывать и ломать у себя что-то и зачем вам вникать в их кухню. А так, как организовали вы, это можно делегировать только админам, да ещё и не простым, а которые понимают, что делают в AD. При моей же схеме вы можете это доверить даже эникею, программисту — ну в крайнем случае — бухгалтеру (но тогда успех не гарантируется (сарказм)).
Надеюсь понятно раскидал. Поиграйтесь с этим, и вы поймёте гибкость моего решения. Главное не забывайте про CNAME… без него будет всё не так красиво и легко.
Там вы ещё про копирование с ключами говорили и что это очень легко… Но, ведь правда же, что вообще не шевелить данные без необходимости куда практичней и проще…
Кстати одна из болезней 1С разработчиков, это любовь к реорганизации базы данных, перестроения таблиц, справочников — будто это файлики какие-то. И от этого все их проблемы. Данные хорошо записывать один раз и не менять их местоположение, тогда не нужно будет переписывать весь свой код занова… Но тогда у нас не будет работы.
И с вашей автоматизацией очень хорошо подчёркивается важность системного администрирования, и наличия Администратора, AD, DFS (что это?! (сарказм))… А! ещё и групповые политики тоже очень нужные!..
А при моей «колхозной автоматизации» вам всё организовать придётся раз, делегировать кому-то и забыть. Понимаете! Забыть! Оно само будет работать без AD, без GPO, без Администратора, без DFS… Хорошо бы ещё и Window нафиг снести… (сарказм).
Надеюсь из всего моего потешательства, вы увидели главную идею и вынесли полезное.
Буду рад, если этот опыт, действительно кому-то сэкономит 100-200 часов работы, может больше. Всё зависит от того, сколько времени вы с этим будете работать и как.
Полагаю разговор идет о 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 часов работы, может больше. Всё зависит от того, сколько времени вы с этим будете работать и как.
а не кучка админов по необходимости на свой лад, по просьбе программиста добавляет права шибко не разбираясь в чужой кухне. Мой вариант для слабо организованных систем.Если эникейщик управляет сервером это не делает его админом.
Пояснить назначение всех групп, 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+ сотрудникам. Их там поименно в доступе прописывают что ли?
Все бы хорошо, но опять приходим к ситуации, когда вы отдали и забыли, а на местах люди сменились и им ничего не передали. В итоге носителей информации ноль.Документация для этого делается один раз.
И может я не до конца понял, но у вас к v8i файлам доступ прописывают 1Сники. Допустим к базе требуется доступ 150+ сотрудникам. Их там поименно в доступе прописывают что ли?Да хоть как! Можете поимённо, можете группам давать. Не мне вас AD учить… Главное, чтобы у человека были права на назначение прав в каталоге. Интересные ему группы он может себе записать, или вы ему списочек с объяснением дадите. Но опыт показывает, что о назначении групп все со временем забывают, и добавляют человека напрямую так, чтобы наверняка и лишнего доступа не дать. Колхоз! Я вам говорю про среднестатистическую фирму с полным бардаком. Вашу, крутейшую организацию я не берусь здесь рассматривать.
Скажу сразу, что сходу у меня по данной схеме реализовать не удалось. Покурю мануал получше, видимо нюансы с подключением есть.Нет никаких нюансов с подключением. Там вообще никаких высших механизмов не задействовано. Курить там не чего. И объяснил я, вроде уже на пальцах. Смотрите кодировку файла. Если это не UTF-8, то этот файл не видится. Я сам регулярно напарывался на то, что в редакторе не смотрел, какая кодировка стоит при сохранении файла, и перекодировал файл в… Какая там кодировка по умолчанию в русской винде?..
Решение было бы очень удобным в контексте того, что на оконечных ПК не нужно обновлять 1CEStart.cfg, и все изменения в корневом файле бы применялись мгновенно. Спасибо за наводку.За наводку пожалуйста. Решение тем и гениальное, что скорость реакции на изменения ровно после нажатия кнопки сохранить в окне выставления прав пользователей или редактирования конфигурационного файла. Групповы политики так никогда не смогут. Идеальный порядок на пользовательских станция (там просто ничего нет, кроме одной строчки), и у вас засрать эту систему можно, как угодно, а потом причесать, как угодно, и пользователь не будет об этом знать. Если, вдруг, лажанул админ, и после реорганизации, кого-то не добавил, то он это делает по звонку целовека, просит пользователя переоткрыть 1С, и в списке появляется нужная база. Если база не появляется, то тут либо проблемы с правами, либо совсем нет связи с сервером, либо связь есть, но она такое говно, что 1С не дождалась ответа при запросе к файлу (а это должны быть потери конские, или пинг не менее конский).
И вот этим вы меня сильно зацепили:
Если эникейщик управляет сервером это не делает его админом.Если человек админ, это не значит, что он всё уже знает о своей области.
Вот, например вы эникеите в области, которую мы с вами здесь обсуждаем. Т.е. тыкаетесь, на основе своего уже имеющегося опыта, не читая документацию и не делая экспериментальных постановок, не анализируя эффективность и лёгкость вашего решения.
И действительно, это очень маленькая задачка, чтобы придавать этому такое большое внимание. Поэтому вы её вывели на верхний уровень администрирования с AD, GPO, DFS (Что это такое?! (сарказм)) и прочим хламом. А я её упростил до эникея, с наименьшими затратам по технологиям, и правками в различных местах одних и тех же файлов. Там всё гениально и просто. Это я не про то, что я придумал, а про то, что разработчики продукта 1С так гениально постарались и продумали. Проблема в том, что они нормально это не описали. И мало кто знает, как гибко это можно организовать.
Прошу прощения, если обидел последними строками.
Sign up to leave a comment.
Легкое управление списками баз 1С