1С-Предприятие 8.2: разворачиваем через GPO+MSI, русский интерфейс на англоязычной ОС Windows
Ранее уже писал о собственном опыте создания MSI пакетов для 1С предприятия 7.7. И никак не ожидал проблем с развёртыванием платформы 1С 8.2 через GPO, благо разработчики уже создали msi пакет для нас. Но, как выяснилось, при развёртывании на станции с MS Windows XP english возникают проблемы локализации – интерфейс на английском. О том, как победили, здесь и напишу.
Сразу оговорюсь, описываю в этой статье не свой опыт, а опыт коллеги (за что ему отдельное спасибо).
Решений для публикации 1С предприятия 8.2, как всегда, много. Опишу решение, которое выбрали мы для себя – через GPO+MSI+GPP.
Публикация платформы и трансформация
Итак, создаём объект GPO. Публиковать платформу мы будем на компьютеры, а не на пользователей. Право на применение политики даём специально созданной для этой цели группе (в моём случае группы безопасности для политик создаётся скриптом).
Теперь запускам редактор политики. Перед сохранением сценария установки (до того, как нажмём “Применить” либо “Ok” в диалоговом окне при публикации msi файла в GPO) не забываем добавить трансформацию 1049.mst (иначе русского интерфейса точно не будет).
Приведу скриншоты:
В дополнительных параметрах развёртывания (страница “Развёртывание”, кнопка “Дополнительно”) опция “Не использовать языковые установки при развёртывании” важна!
Ресурсы на месте, где же локализация?
Можно было ожидать, что на этом проблемы закончатся, но не тут то было! Если бы ОС была русскоязычной – интерфейс уже был бы локализованным. В моём случае – локализация ОС за счёт MUI. Поиск по форумам вывел на одно решение – создание файла ru.res в каталоге конфигурации платформы.
Вариантов для создания файла файла несколько. Править msi через mst – дело не сложное,и можно получить несовместимость с последующими редакциями msi платформы. Поэтому выбрали вариант с GPP.
Путь к создаваемому файлу — %programfiles%\1cv82\conf\ru.res. Исходный файл с тем же именем положили (файл пустой) в соответствующий каталог административной точки установки.
И на этом всё – при запуске платформы получаем русскоязычный интерфейс, что и требовалось.
Публикуем информационные базы
Всё, да не всё. Хочется ведь и базы зарегистрировать у пользователей, причём так, чтобы каждый пользователь видел только те базы, которые ему видеть положено. И опять для этих целей используем GPO.
В отличии от платформы 7.7, 8.2 регистрирует базы не в реестре, а в файле в профиле пользователя – %appdata%\1C\1CEStart\ibases.v8i.
Итак, создаём ещё один объект GPO и группы безопасности для него, в которые включаем уже пользователей, которым необходимо предоставить доступ к конкретной информационной базе. И редактируем групповую политику.
Так как конфигурационный файл для платформы 8.2 представляет собой, по сути, ini файл, и вносить изменения в него будем при помощи аплета “ini-файлы” GPP (картинка слева) . Да, для каждой базы потребуется такое количество записей, мы же должны заполнить целую секцию в ini файле. Чтобы не приводить кучу картинок, покажу файл из sysvol-part нашего объекта GPO (\\домен\sysVOL\домен\Policies\GUID Вашего GPO\User\Preferences\IniFiles\IniFiles.xml):
<?xml version="1.0" encoding="utf-8"?>
<IniFiles clsid="{694C651A-08F2-47fa-A427-34C4F62BA207}">
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}"
name="Connect"
status="Connect"
image="2"
changed="2011-10-04 10:03:03"
uid="{82EEF6AF-08E9-4266-A01D-034E38B55ACF}"
userContext="1"
bypassErrors="0"
>
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="Connect"
value="File="\\novgaro.ru\files$\DB\1C\Enterprise\SALARY\13s201109gcg";"
/>
</Ini>
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}" name="ID" status="ID" image="2" changed="2011-10-04 10:03:16" uid="{61B01BD2-9DEC-42C1-BD3E-0EB62049E132}" userContext="1" bypassErrors="0">
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="ID"
value="e05aa2b1-b7d6-4728-8ed8-cafde0f7ab18"
/></Ini>
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}" name="Folder" status="Folder" image="2" changed="2011-10-04 10:17:28" uid="{FAF03ED6-F66C-4CBF-AA0E-4ADA7A77E39D}" userContext="1" bypassErrors="0">
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="Folder"
value="/GARO group"
/>
</Ini>
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}" name="External" status="External" image="2" changed="2011-10-04 10:03:07" uid="{CACCC169-00A6-4561-B3EB-A428490EDAC9}" userContext="1" bypassErrors="0">
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="External"
value="0"
/>
</Ini>
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}" name="ClientConnectionSpeed" status="ClientConnectionSpeed" image="2" changed="2011-10-04 10:02:59" uid="{6C775CE8-C850-4E07-A5CB-54234526E88E}" userContext="1" bypassErrors="0">
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="ClientConnectionSpeed"
value="Normal"
/>
</Ini>
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}" name="App" status="App" image="2" changed="2011-10-04 10:02:45" uid="{CBDAB0BD-89A9-4B1F-82AB-4037219E2F34}" userContext="1" bypassErrors="0">
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="App"
value="Auto"
/>
</Ini>
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}" name="WA" status="WA" image="2" changed="2011-10-04 10:03:36" uid="{C7F8FAB5-40C9-437C-BAAD-E4BE8922D0B7}" userContext="1" bypassErrors="0">
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="WA"
value="1"
/>
</Ini>
<Ini clsid="{EEFACE84-D3D8-4680-8D4B-BF103E759448}" name="Version" status="Version" image="2" changed="2011-10-04 10:03:32" uid="{05FB46F6-16F5-4BB1-B0F5-CB45F634EE85}" userContext="1" bypassErrors="0">
<Properties path="%appdata%\1C\1CEStart\ibases.v8i" action="U"
section="GARO group - Salary"
property="Version"
value="8.2"
/>
</Ini>
</IniFiles>
Дам несколько пояснений. То, что мы пропишем в наименовании секции ini файла (section), и будет видеть пользователь в окне выбора информационной базы. К сожалению, API Windows работает с ini файлами как с не unicode файлами (а GPP использует указанное API для нашей задачи). В результате, файл %appdata%\1C\1CEStart\ibases.v8i сохраняется как не unicode файл. А платформа 1С ожидает unicode файла. В общем, я не нашёл способа использовать в этом файле кириллицу (только через GPP, руками можно писать всё, что угодно), поэтому и пришлось писать транслитерацией.
Параметр Folder позволяет нам определить “папку”, в которую будет включена наша информационная база, если пользователь выберет режим отображения списка в виде дерева.
В таком варианте публикации информационных баз есть свои плюсы – сведения в профиле пользователя будут изменены даже без перезагрузки, при очередном применении политик. И если пользователь что-либо “исправит” – достаточно выполнить gpupdate /force – и всё вернётся на место.
Решений всегда много
Да, так часто говорит один мой коллега по работе. И в нашем случае данное высказывание так же верно. Публиковать базы можно и иначе – создавать свои ярлыки на 1cestart.exe, при этом указывая ссылки на файлы .v8i для конкретной базы. В этом случае самым простым решением будет размещение .v8i файла в каталоге информационной базы, и той же политикой, что и выше, также через GPP создаём ярлык в меню пользователя.
Вот такая вот автоматизация.
Отзывы » (37)
Связь с комментариями статьи:RSS комментарии
Обратная ссылка
Станицы 
Рубрики 
Облако ключевых слов 
RSS анонсов статей 
Windows 7 
Городские огни 
Characters 
Landscape 
Nature 
Shapes ![[-]](http://sergey-s-betke.blogs.csm.nov.ru/wp-content/themes/inanis-seven/images/st_link.png)
Добрый день, Сергей. Спасибо за статью. Я, вот, тоже посматриваю в сторону автоматизации установки 1С, в связи с этим у меня возник вопрос, на который я пока не могу найти ответ. Вопрос такой: каким образом можно в назначенном при помощи GPO пакете MSI можно указать компоненты, которые подлежат установке на клиентскую машину? Документация 1с на этот счет очень скупа (в ней просто декларируется возможность установки через GPO), однако подробно расписан способ установки при помощи Logon-скрипта и приведен сам скрипт (его можно посмотреть здесь). Из скрипта становится понятно, что компоненты, которые требуется установить на клиентскую машину, задаются при помощи параметров командной строки msiexec вида proerty=propertyvalue (например: THICKCLIENT=1 THINCLIENT=1 WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=0). правильно лия понимаю, что вместо того, чтобы указывать эти параметры в командной строке msiexec, я могу добавить эти параметры и их значения в секцию Property пакета msi (например при помощи mst) и тем самым добиться желаемого результата?
В общем и целом — абсолютно правильно. Да, Вы не правите исходный msi, Вы создаёте трансформацию с помощью Orca, прописываете нужные Вам свойства в таблицу Proeprty (регистр важен, не забывайте об этом). И при публикации msi в GPO указываете созданную Вами трансформацию. Результат будет.
P.S. Кстати, буду Вам благодарен, если сообщите, какой путь выбрали для публикации «ярлыков» к базам 1С.
Определился с ярлыками. Вернее, не столько с ярлыками, сколько с добавлением баз в список общих информационных баз, который видит пользователь при запуске 1c. Описал кратенько у себя в бложике: http://shserg.ru/posts/deployment_1c_v82_group_policy/
Огромное спасибо за предложенное решение! Действительно, куда более красивое решение, лишённое описанных недостатков и менее трудоёмкое в администрировании. Попробую применить, поправлю статью, с обязательной ссылкой на Ваше решение, безусловно! Ещё раз спасибо за красивое решение.
Однако, с файлом %APPDATA%\1C\1CEStart\1CEStart.cfg своя беда — это не ini файл (хотя что мешало сделать его ini файлом?). Посему внести в него необходимые записи через GPP не выйдет. Хотя — попробую создать «фантомную» секцию в этом файле и внести изменения через GPP в неё, после чего посмотрю на реакцию 1С. Результаты сообщу.
Ещё одна беда с этим файлом:
Как видно, мало того, что секций нет, так ещё и имеем несколько записей для одного и того же параметра, что недопустимо для ini файла. Применение GPP ещё больше осложняется. Буду дальше разбираться. По-прежнему, склоняюсь к созданию скрипта генерации msi пакетов под каждую базу с автоматической генерацией политик распространения этих пакетов на пользователей… а в msi — сценарием при установке создавать запись в указанном Вами файле и ярлык в меню (можно и на рабочем столе опционально).
Провёл серию экспериментов, могу сказать следующее. Вполне работает такой вариант файла %APPDATA%\1C\1CEStart\1CEStart.cfg:
Естественно, при этом 1С секции игнорирует, а мы можем себе позволить править этот файл через GPP через апплет (и API) ini файлов. Всё работает, достаточно удобно. Но один недостаток — при запуске 1С все перечисленные .v8i файлы импортирует в ibases.v8i. И даже после удаления из .cfg файла ссылки на конкретный .v8i файл его записи остаются в ibases.v8i. Другими словами, опубликовать базы через политики мы можем, а «удалить» публикацию этих баз — уже нет.
Но зато решается проблема с локализованными описаниями баз. И трудоёмкость куда меньше (через GPP только одну запись добавить, а не целое множество).
P.S. Должен сказать, что и в моём решении «удаление» базы — не очевидная процедура. Просто вывод пользователя из зоны действия GPO эффекта не даст. Так что пока обсуждаемое решение лучшее из предложенных, спасибо ShS!
P.P.S. и для последующего сценария с генерацией msi файла для публикации / «удаления» конкретной базы удобнее будет использовать .v8i файл конкретной базы. А при «удалении» — находим все секции в v8i файле «удаляемой» базы и удаляем их в ibase.v8i — выглядит всё просто и удобно.
P.P.P.S — а на .v8i файл базы можно и ярлык опубликовать. Итого — целесообразность размещения в каталогах баз индивидуальных .v8i файлов обсуждать нет смысла — однозначно целесообразно!
Интересный способ, надо будет потестировать.Я пробовал способ описанный в самой статье. Пробовал указывать не все записи, а только Connect. Остальное 1с сама дописывает при первом запуске такой базы. Локализации добивался за счет указания имени секции кракозябрами.
Т.е. брал нужное имя в UTF менял кодировку на вин1251 и получал кракозябры. Вот их и пишем в имя секции, GPP пишет в нужный файл в кодировке вин1251 кракозябры, а 1с при запуске их уже читает в UTF и получается русский. Сложный и тернистый путь получается. Сейчас попробую метод описанный в комментарии выше.
Однако, про вариант локализации «кракозябами» не подумал. Спасибо, Владимир. Но вариант, предложенный в комментариях ShS, удобнее, и без «кракозяб». А удобнее тем, что Вы «нативно» правите .v8i для базы, а затем через GPP только одну строку дописываете — и всё замечательно. Беда только в том, что наименование менять потом нельзя (так как оно же — идентификатор секции).
И он (предложенный вариант) — работает (я попробовал, вариант оформления файла секциями (чтобы через GPP можно было править) привёл в комментариях).
> Кстати, буду Вам благодарен, если сообщите, какой путь выбрали для публикации «ярлыков» к базам 1С.Пока еще не думал над этим. Да, еще забыл спросить, а перед добавлением msi пакета 1с в политику, выполняли ли вы предварительно административную установку или добавляли пакет непосредственно из дистрибутива?
Я всегда предварительно готовлю административную точку установки, взял за правило. Поясню смысл сего действа. Если в msi пакет запакован cab, тогда при публикации в GPO этого пакета при установки любого набора компонентов продукта (даже при публикации без установки как таковой) на рабочую станцию будет загружен весь пакет, развёрнут, и с него будет сделана установка. Естественно, после установки загруженный пакет удалён не будет. Итого — лишний трафик по сети (при существенном количестве рабочих станций утро может стать недобрым), лишнее место на накопителях на рабочих станциях.
Если же предварительно подготовлена административная точка установки, копируется на рабочую станцию только msi, который, как правило, на порядки «легчает». И устанавливаются непосредственно с сетевого ресурса только необходимые компоненты. И для сети легче, и для рабочих станций. Посему мой Вам совет — всегдя готовьте административные точки установки перед публикацией в GPO.
Спасибо. Из ваших объясений я понял, что у метода развертывания приложения без создания административной установки есть не только минусы, но и плюсы: пакет копируется на локальную машину, а, значит, им можно пользоваться автономно, например, когда компьютер не будет подключен к сети, можно будет добавлять\удалять компоненты при помощи оснастки «установка и удаление программ». так? И еще один вопрос: под административной у становкой вы понимаете установку выполненную при помощи команды msiexec /a …? Дело в том, что у 1с есть возможность выполнить «административную установку» при помощи запуска setup /a. Я не знаю - будут ли результаты выполнения административных установок при помощи msiexec и setup тождественно равны друг другу? Какой способ создания административной установки 1с используете вы?
Я всегда использую
msiexec /a. Проsetup /aв случае 1С не скажу, не использовал.Касательно плюсов «нераспакованных» msi в GPO — да, Вы правы, такой плюс имеет место быть, если только политиками не запрещено (а можно и запретить). Именно поэтому для некоторых продуктов (офис, в частности) у меня две разные политики — для «резидентов» и «нерезидентов». Соответственно, в первом GPO — с административной точки установки, во втором — «запакованный» msi пакет.
Спасибо за проделанную работу! Почерпнул много полезного для себя. Для ярлыков лучше всего использовать перемещаемый рабочий стол. Права пользователям поставить только для чтения, чтобы не захламляли чем попало а хранили все в «Мои документы».
Благодарен за высокую оценку. По ярлыкам: Вы, видимо, имели в виду «назначенный» рабочий стол. Рабочий стол и профили и так у меня перемещаемые (roaming profiles). Назначенный рабочий стол далеко не всегда применим, достаточно жестокое решение. Я вижу задачу обычно иначе — полностью автоматизировать процесс установки, при этом не ограничивая пользователя излишне (естественно, и так они все — просто пользователи, никаких, в том числе и локальных, повышенных привелегий не имеют, да и политиками много чего закрыто, но ярлыки на рабочем столе, их оформление и прочее — не вижу смысла в излишней навязчивости). К тому же, возможных конфигураций назначенного рабочего стола будет очень много (одни ставим один софт, другим — другой, имеем уже 4ре варианта, а в моём случае их будет несколько десятков).
Посему назначенный рабочий стол для меня не вариант (кстати — во всех пакетах вырезаю трансформацией публикацию ярлыков на рабочий стол, оставляю его полностью на усмотрение пользователей, msi пакетами через GPO публикую ярлыки только в меню, иногда — в меню быстрого запуска, но не более).
Да и в случае 1Cv8 вопрос про ярлыки больше был не в том, каким образом эти ярлыки лучше раскинуть, а в том, на что ярлыки. Вносим изменения в файл %appdata%\1C\1CEStart\ibases.v8i, или же делаем массу ярлыков на на 1cestart.exe, указывая в параметрах ссылку на .v8i файл для конкретной базы.
Для 1Сv7 я пошёл другим путём. В пакете самой платформы опубликовал (именно — опубликовал в терминологии msi) тип файла .md. В таком варианте любой ярлык на .md файл спровоцирует механизмы самопроверки и самовосстановления пакета msi, чего и хотел добиться.
Для 1Cv8 вариант с «самопальными» ярлыками на 1cestart.exe не вызовет самовосстановления пакета, что нехорошо (не хочется задумываться о том, что под каким-либо пользователем какая-либо компонента 1C окажется незарегистрированной, об этом должен msi позаботиться). Поэтому и пошёл по варианту внесения изменений через GPO в %appdata%\1C\1CEStart\ibases.v8i.
В общем, вопрос остался открытым: каким образом разумнее публиковать ярлыки на «базы», обеспечив при этом и удобство администрирования, и механизмы восстановления / установки msi. Для 7ки вопрос решил сам (хотя тоже и не с первого, и не со второго раза до него дошёл), а с 8кой разработчики явно не «додумали» этот момент, посему вопрос остался открытым.
Огромное спасибо за xml. Как то вообще не догадался об этом, хотели просто подменять клиентский файл, но вопрос возникал с «личными» базами. А теперь получается полностью управляемый вариант, и для пользователей пройдет незаметно любая миграция и изменения.
Да, именно эту цель и преследовал. Одна проблема — кириллицу использовать нельзя.
Нашёл замечательную статью на тему решения проблем с обновлением установленных через GPO пакетов 1С 8.2 — kvazar.wordpress.com. Проблема решается либо описанным в статье способом, либо через явное указание при публикации пакета в GPO на замену (а не обновление) предыдущего пакета.
Для руссификации можно попробовать следующий танец: Платформа 8.2.15, думаю что работает и на более ранних. В административной установки находим файл «program files\1cv82\conf\conf.cfg». В нем значение единственного параметра меняем на RU (для русского) или EN (для английского). Ну а дальше ставим через ГПО. Или же после установки модифицируем его (conf.cfg) как ini файл, тоже должно сработать.
Спасибо большое, Владимир. Попробую Ваше решение (оно, безусловно, более красивое, нежели создание файла через GPP или внедрение этого файла через mst). О результатах сообщу.
Судя по описанию этого файла, он должен содержать только один параметр — ссылку на местоположение файлов .cfg. И уже в них может быть указан язык.
Сергей, обращаю внимание на путь к файлу:»..\program files\1cv82\conf\conf.cfg»а не»..\program files\1cv82\8.2.15.289\bin\conf\conf.cfg»В первом прописывается конкретно язык (он нам в данном случае и нужен), а во втором путь к первому :)К сожалению у меня нет систем с MUI, но судя по моим изысканиям этот метод должен сработать. Очень интересно было бы прочитать о результатах тестов.
Спасибо, Владимир. Таким образом действительно можно действовать, но файл придётся создавать (его нет в исходном дистрибутиве). И беда в том, что он не ini (без секций), посему через GPP его править сложно будет, а замещать его… В общем — попробую, о результатах напишу.
Мой метод применим при административной установке. Проверил на 8.2.14.540 и 8.2.15.289 этот файлик есть. Если установка НЕ административная, его можно просто заменить на нужный нам через политики. Кстати там рядом еще лежит файлик nethasp.ini я его тоже разиваю измененый что бы сеть не забивали широковещательными запросами при поиски ключа лицензий.
nethasp.ini править необходимо, это правильно. Об этом в статье я умолчал, каюсь. Но его всё-таки лучше править через GPP, мне кажется. При этом в случае изменения местоположения сервера правим групповую политику — и у всех всё хорошо. Либо придётся «разливать» всё заново. Хотя в Вашем случае не будет каждые полтора часа файл переписываться одной и той же информацией, что тоже благо…
Касательно conf.cfg. Редакция 8.2.14.533. Установка административная (в терминологии msi — подготовлена административная точка установки). Указанный файл присутствует, содержимое следующее:
При этом в результате установки в C:\program files\1cv82\8.2.14.533\bin\confон оказывается в виде:
а по указанному пути файлов нет, естественно. Его придётся «добавлять» тем или иным способом. В принципе, решение ближе к рекомендациям 1С, чем то, что я описал. Хотя минусы и плюсы практически те же.
Отличная статья. Подталкивает в нужном направлении, вот только почему то более одной базы прописать не удается. появляется либо одна, либо другая.Может это быть связано с тем что затирается опция (например, Connect) первая в файле без привязки к секции?
Всё работает, Владимир, и для нескольких баз. Обратите внимание на аттрибуты
sectionв элементахProperties— для каждой «базы» должна быть своя уникальная секция. Именовать Вы их можете по своему, как Вам будет удобнее и понятнее. Установите пожалуйста для каждой базы свою секцию и попробуйте ещё раз. Сообщите пожалуйста о результатах и в случае успеха, и в случае проблем.Моя ошибка была в выборе действия нужно обновлять (
action="U") и тогда получается несколько баз, но вот если любое другое действо, то уже не получается несколько баз. Пока не разобрался почему.А другие действия нам не подходят — файл то уже есть, удалять записи нам точно не надо, и если они есть — их надо точно заменить. Едиственный вариант — update.
В том то и дело что нужно Обновлять (Update), а я пробовал Заменять. Похожие действия, из-за чего возникает путаница.
Честно говоря, пока разбирался с GPP, тоже долго не понимал различий в режимах применения преференций
Наткнулся в сети на ещё одно решение по публикации баз — http://www.dev.citykirov.ru. Планирую попробовать его в деле, идея выглядит очень «удобно» и правильно с точки зрения GPO.
Подготовил развёртывание этого пакета (gp1cv8ib) через GPO, через редактор GPO опубликовал одну базу. На днях поправлю статью опишу это решение более подробно. Пока что оно мне понравилось больше всех :-). В статье дам ссылки на пакеты установки этого расширения групповых политик.
Данное расширение групповых политик создаёт в sysvol part объекта GPO файл \\domain.ru\SYSVOL\domain.ru\Policies\{GPO-GUID}\User\1C\1cv82\iblist.v8i:
Естественно, этот файл можно и руками править, или скриптами — как кому удобнее, редактор расширения групповой политики прекрасно примет Ваши «рукопашные» изменения (проверено).
Ну а дальше — уже штатная «интеграция» на клинте, которую реализует описываемое расширение групповой политики на клиенте. Его (расширения) плюс в том, что при удалении базы из GPO описание базы будет удалено и на клиентах.
Прелестное решение, автору респект огромный. Лишнее подтверждение тому, что администратору следует уметь не только создавать трансформации msi пакетов, но и свои создавать, да и на создание своих расширений групповых политик так же время стоит потратить.
P.S. В ближайшее время подробно с картинками опишу в статье применение этого решения для публикации баз, я для себя выбор сделал. Коллеги, буду благодарен Вам за отзывы об использования данного решения.
Жду с нетерпением статью. Пока бегло пробежался по оригиналу, не совсем понял. Видимо нужно включать мозг…
Пока наткнулся на проблемы с развёртыванием — явно не все зависимые .dll включены в .msi. И пока что имею проблемы с применением этого расширения на клиентах — возникает ошибка. Разберусь до конца — обязательно опишу.
Ну так как? Пользуетесь?
[…] В этой строке скрипта формируется командная строка , которая будет передана на обработку установщику msiexec. Как мы видим, в эту строку добавляются параметры вида “Property=PropertyValue”. Разумно было бы предположить, что каждое из этих свойств должно найти свое отражение в таблице Properties msi-пакета. Заглянув в msi-пакет при помощи редактора Orca (о том, как “добыть” этот редактор, уже было написано ранее в моем блоге), я не увидел ни одного из этих свойств в пакете 1c. Поэтому, на всякий случай, проконсультировался на этот счет у Бетке Сергея, и он п…. […]