Нужно сделать административную установку групповыми политиками домена. Создали политику с пакетом установки для компьютера, а не пользователя (админские права у пользователей отсутствуют по требованиям безопасности). Для распространения политики создана группа домена, в которой указаны необходимые компьютеры.

Возник вопрос по копированию конфигов.
Для копирования конфигурационных файлов (списки баз и файлы лицензий) используется батник.
- Если указать этот батник в политике в скриптах автозагрузки копьютера, то, я так понимаю, он запустится от localhost\system, а мне нужно от пользователя, чтобы выполнить копирование файлов в пользовательские каталоги.
- Если же указывать скрипт в logon'e пользователя, то, видимо, нужно создавать дополнительную политику и вести для неё группу пользователей (а не компьютеров) домена.

Подскажите, как правильно разрулить эту ситуацию? Для пользователя необходимо выполнить копирование файла 1CEStart.cfg и еще одного дополнительного (не суть) в пользовательские каталоги, которые различаются в XP и Win7.

Доп. вопрос:
Можно ли указать путь к пользовательским каталогам различных версий Windows универсально?:
"С:\Documents and Settings\%username%\Application Data\1C" - для XP
C:\Users\%username%\AppData\Roaming\1C - для Win7

Для этих целей мы используем расширение групповой политики AD для списков баз 1С: GP1CV8IB
http://dev.citykirov.ru/

(1) достаточно ли .msi и Data1.cab для установки?

(1) файлы трансформации используете?

(2)нет, нужен ведь еще сам msi
(3)используем только штатный для языка 1049.mst

(1) спс, видел этот линк. Если им можно разрулить базы, то как мне сделать копирование доп. файла? Всё-равно придется создавать группу пользователей для возможности копирования? (если интересно объект копирования - конфигурационный файл СЛК 2.0)

(0) > Можно ли указать путь к пользовательским каталогам различных версий Windows универсально?

%appdata%

(6) спс

(5) а где его надо размещать?

(8) в пользовательском каталоге
%appdata%\Licence 2.0\

(вопрос к тем, кто работает с СЛК 2.0. М.б. можно задать сервер по умолчанию, чтобы при первом коннекте к базе, он не задавал вопрос о месте размещения лицензии?)

(5)может его просто ставить всем вместе с платформой? тогда любым сборщиком msi сделать свой дистрибутив и включить его в объект ГП чтобы ставился вместе с платформой?

а, платформа на комп, а тут юзер нужен..

ну по идее тогда надо все равно делать свой msi? который ставит все что надо в %appdata%\Licence 2.0\ и вешать его установку в отдельный объект ГП в раздел Конфигурация пользователя, с областью применения по группе пользователей.

(12) да, как раз и не хотелось заводить доп. политику и вести группу пользователей, поэтому:
(10) я решил копировать этот файл средствами 1С, как раз перед проверкой лицензии.
А (1) буду пробовать. Спс.

кстати, в (9) опечатка %appdata%\1С\Licence 2.0\

(12)+ или дописать GP1CV8IB, чтобы оно что нибудь еще в профиле пользователя могло подшаманивать, кроме списка баз.
:o)

(15) смотрю http://www.dev.citykirov.ru/GroupInstall1CEnt.htm
можешь попроще объяснить? Я так понял нужно дополнительно к установке 1С еще и добавить в созданную политику установку этого пакета расширения? А где тогда настраивать базы, если он пишет, что на контроллере домена не обязательно устанавливать? Или на контроллере тоже нужно установить и там настраивать?

(15) смотрю в описании к http://dev.citykirov.ru написано "добавлена возможность настройки информационных баз 1С 8.2". Где и какой файл он будет создавать? Вы для 8.2 используете?

(1) Насколько я понял, судя из описания из заголовка скриншота в http://www.dev.citykirov.ru/GroupInstall1CEnt.htm
("Область применения объекта групповой политики удобнее всего задавать группой безопасности AD, а потом просто включать пользователей AD в эту группу.")
эта методика реализуется дополнительной группой пользователей, т.е. для установки 1С вы ведете группу компьютеров, а для установки баз - группу пользователей?

+(18) "и заголовка скриншота"

1.устанавливать надо на всех компьютерах где она может применяться либо настраиваться.
Это по сути всего одна dll которая регистрируется в windows особым способом (как расширение ГП). Например установка программ в ГП это тоже расширение ГП, только ее написали в MS. Она служит для 2х функций: применения политики и настройки этой политики через консоль mmc (понятно что настраивать сможет только тот у кого права есть). Технически можно было сделать 2 dll, а практически в этом смысла нет.
Если непосредственно на контроллере домена эти объекты политики ни применяться ни настраиваться не будут то и устанавливать туда ее незачем. Однако данные этой политики будут храниться именно на контроллерах домена в каталогах AD.

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

(21) т.е. у вас одна политика, в которой 2 пакета:
- на установку 1С
- на установку GP1CV8IB
Политика применяется к группе компьютеров, а не пользователей?

если можно еще ответ на (17)

+(22) базы настраиваются на контроллере домена, где также вручную нужно установить GP1CV8IB?

3.Конечное решение выглядит так:
3.1 есть группа безопасности, которая стоит в области применения объектов ГП с установкой 1С и GP1CV8IB. В которую добавляются компьютеры. Когда нам надо чтобы на компьютере была платформа, мы включаем его в эту группу.
3.2 есть группа безопасности, которая стоит в области применения объекта ГП с установкой базы 1С. В которую добавляются пользователи. Когда нам надо чтобы пользователю была доступна эта база, мы включаем этого пользователя в эту группу.
3.3 На каждую базу своя группа безопасности и свой объект ГП.

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

3.4 когда надо убрать доступность базы, мы убираем его из группы базы, и после применения запись о базе у него исчезнет.

(24)(25) понятно... в общем-то суть вопроса в (0) была в том, как бы сделать так, чтобы не заводить вторую политику для баз, а также не вести дополнительную группу пользователей...

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

(27) это всё понятно. смотри (26)

дело в том что у нас много разных баз.

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

(28)Если база одна тогда можно и одну группу сделать, в которую включать и компы и пользователей, а в объекте ГП прописать и то и другое (и установку 1С и установку базы).

ну или одинаковый список баз

в объекте ГП можно несколько баз прописать

(31) из (0):
Для копирования конфигурационных файлов (списки баз и файлы лицензий) используется батник.
- Если указать этот батник в политике в скриптах автозагрузки копьютера, то, я так понимаю, он запустится от localhost\system, а мне нужно от пользователя, чтобы выполнить копирование файлов в пользовательские каталоги.

если я в объекте политики укажу установку 1С в конфигурации компьютера, а копирование файла в конфигурации пользователя, то будет ли эта политика работать, если я распространю её на группу компьютеров, а не пользователей?

Если ты его пропишешь в разделе конфигурации пользователя, то применение будет когда пользователь зайдет, а не когда комп загружается, соответственно текущий профиль должен быть уже определен, и %appdata% должен указывать куда надо.

Надо пробовать, я точно не могу сказать будет ли применяться политика пользователя для всех пользователей, которые заходят на компе, который входит в область применения этого объекта ГП.

Чета я сомневаюсь что будет..

(17)изначально все писалась когда еще 8.1 была, потом дорабатывалась для 8.2. С 8.3 работает без изменений, у нас сейчас только 8.3.

(36)(37) вот и сисадмин мне сходу не смог ответить на этот вопрос, поэтому эта тема возникла в поисках других вариантов. Но всё-таки, если бы конфигурация компьютера однозначно была в рамках группы компьютеров, а конфигурация пользователя в рамках группы пользователей, то MS разделила бы эти политики на 2 схемы.
Думаю, всё-таки windows умный и по идее правильно разрулит эту ситуацию и скопирует файл всем пользователям, которые выполняют logon с конкретного компьютера (входящего в группу компьютеров, на которую распространена эта политика).

так чо тут думать/гадать, надо попробовать да и все

опыт провести :)

(38)(42) опыт провели + админ сказал, что "не будет работать. Потому что политика работает либо на юзера либо на компьютер, одновременно на юзера и на компьютер не работает. Т.к. юзеры под нее не попадают."

Почему-то у меня не работает файл трансформации дополнительный. В нем я хотел ограничить установку только толстым клиентом:
THICKCLIENT 1
THINCLIENT 0
WEBSERVEREXT 0
SERVER 0
CONFREPOSSERVER 0
LANGUAGES RU
CONVERTER77 0
SERVERCLIENT 0

, но почему-то всё-равно ставится по умолчанию (тонкий клиент в том числе).

+(43) придется вести 2 группы

мне кажется один объект ГП может работать одновременно на комп и на юзера (там ведь два разных раздела, но они никак друг от друга не зависят и не влияют), просто в области применения должны быть и комп и юзер.
Понятно что в вашем случае это не поможет, лучше тогда две группы.

Такой файл трансформации конечно можно сделать, но хлопотно это, у них там еще хренова гора скриптов выполняется (они прямо внутри msi), разбираться с этим великолепием нет никакого желания, я бы на твоем месте просто забил на это.

займись лучше действительно полезным делом: разработай свой MSI для установки файлов в %appdata%\Licence 2.0\
Чтобы установить его в раздел объекта ГП "Конфигурация пользователя" в Установку программ.

Logon script это ведь фигня по большому счету: он же при каждом входе выполняться будет.

Можно еще список баз - выложить на общий ресурс.

C:\ProgramData\1C\1CEStart\1cestart.cfg - заменить на свой, настроенный на все базы, через ссылки, лежащие на общем ресурсе.

Как - то сложно описалось, но думаю понятно.

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

(47)(ссылки типоразмера *.v8i)

(45) админ, несмотря на (43), в итоге сделал только через пользователя: и установку платформы, и logon-скрипт.
Думаю над тем как лучше поступить с 1cestart.cfg. Сейчас logon-скрипт копирует 2 файла: 1cestart.cfg и файл конфигурации СЛК 2.0. При удалении пользователя из группы: платформа удалится, а файлы останутся. Вобщем-то не критично, но и не совсем правильно. Можно добавить еще logoff скрипт на удаление файлов. Но получается сложная схема.
(46) Насчет msi - не заморачивался, пока только с mst разобрался.

Подскажи, какой файл в итоге создает GP1CV8IB для 8.2? Про GPIBList.v8l не нашел информации. Где прочитать?

(49) Думаю, описка там, *.v8i, что по правой клавише мышки из списка баз выгружаются в файлы. )

(50) Не суть. Даже если GPIBList.v8i - что это за файл и где он расположен?

в (1) ссылка, там все описано. Кроме того можешь этих файликов сам насоздавать...

(51) http://v8.1c.ru/overview/commonbases.htm?printversion=1

О вот, поиск рулит... Тут подробнее о том что я писал в (49):
v8: Никак не могу победить *.v8i