Меню Рубрики

Установка 1с по сети используя msi

Сценарии установки 1C 8.2 — 1C 8.3: способ 2: патчинг MSI файла

Для того, чтобы устанавливать программное обеспечение с помощью групповых политик, необходимо использовать не exe/cmd/bat, а только MSI файл (возможно с добавлением файлов-модификаций: MST файлов).

В стандартном комплекте установки 1С не предусмотрено наличие файла конфигурации, который бы позволил сделать «тихую» установку 1С из MSI файла (т.е. без каких-либо вопросов пользователю).

Для того, чтобы реализовать такой функционал и устанавливать 1С с необходимым набором компонент через групповые политики (т.е. с использованием MSI файла), мы создадим собственный файл модификаций (MST файл).

Для создания и редактирования MSI и MST файлов можно использовать различное программное обеспечение. Одним из распространенных вариантов является программа Orca.

Редактирование установки 1С с помощью Orca

После скачивания и установки запускаем программу Orca и открываем в ней файл установки 1С «1CEnterprise 8.msi». Т.к. разработчики 1С не рекомендуют менять msi-пакет, идем в меню «Transform» => «New Transform».

Открываем таблицу «Property» и редактируем:

  1. Изменяем значение поля «DEFLANGUAGE»: вместо «Auto» пишем «RU» (без кавычек)
  2. Добавляем новые поля (новые поля можно добавить комбинацией клавиш Ctrl+R):
    DESIGNERALLCLIENTS = 1
    THINCLIENT = 1
    THINCLIENTFILE = 1
    SERVER = 0
    WEBSERVEREXT = 0
    CONFREPOSSERVER = 0
    SERVERCLIENT = 0
    CONVERTER77 = 0
    LANGUAGES = RU

Для того, чтобы создать файл трансформации (.MST) с указанными параметрами, идем в меню «Transform» => «Generate Transform…». Сохраняем файл в папку с дистрибутивом. Название можно дать, например Client.mst . На этом генерация файла транформации закончена.

Проверка установки 1С с файлом трансформации

Чтобы проверить установку 1С с помощью созданного файла трансформации (MST файла), необходимо открыть командную строку. Перейдите в папку с дистрибутивом 1С и выполните команду:
setup.exe /S TRANSFORMS=Client.mst TRANSFORMS =1049.mst
или
msiexec /i » » TRANSFORMS= » » \Client.mst TRANSFORMS= » » \1049.mst /passive
В первой команде параметр «/S» и во второй команде параметр «/passive» означает, что установка будет проходить в «тихом» (фоновом) режиме. Подождите несколько минут и проверьте факт установки 1С. Должны установиться следующие компоненты: Толстый клиент, Тонкий клиент и русский интерфейс.

Теперь можно производить установку 1С через групповые политики с использованием MSI файла «1CEnterprise 8.msi» и созданного нами файла трансформации — MST файла client.mst

Источником данной статьи послужили следующие материалы:

источник

Установка 1с по сети используя msi

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

Существует несколько способов групповой установки программы 1С:Предприятие.

Если в сети применяется доменная структура Microsoft Active Directory, то удобно распространять установочные пакеты программ на рабочие компьютеры с помощью групповых политик. В дистрибутиве программы 1С:Предприятие присутствует необходимый для развёртывания через групповые политики установочный файл с расширением .msi.

Другое решение – групповая установка с помощью логон-скрипта. Этот способ описан в ИТС и в документации по программе.

И ещё групповую установку программы 1С можно организовать небольшими bat-скриптами вкупе с каким-нибудь инструментом, который позволяет устанавливать программу в сеансе обычного пользователя, но с правами администратора. Таким инструментом может быть, например, бесплатная для некоммерческого использования программа RunAsSpc (сайт разработчика http://www.robotronic.de/runasspcEn.html). Вот этот метод мы и рассмотрим подробнее.

Итак, скачиваем дистрибутив прораммы RunAsSpc. Запускаем файл runasspcadmin.exe. В форме программы указываем учётные данные администратора, а также путь к файлу, который мы хотим запускать с правами администратора. Мы могли бы указать путь к файлу 1CEnterprise 8.msi, но в таком случае потребуется предварительно сконфигурировать этот файл с помощью специальной программы, например Orca. Конфигурирование подразумевает под собой выбор компонентов к установке, выбор языка установщика, языкового пакета программы и прочее. Мы не будем править установщик .msi, а вместо этого создадим bat-скрипт, в котором укажем параметры установки. И вот этот-то bat-скрипт укажем в форме программы runasspcadmin.exe.

Сам bat-скрипт состоит всего из одной строки:

Параметры, которые можно настраивать в bat-скрипте:

/qr – Сокращенный интерфейс. По сути, при установке пользователь увидит только бегущую полосу прогресса. Можно указать /qn и юзер вообще ничего при установке не увидит.
TRANSFORMS=adminstallrelogon.mst;1049.mst – Здесь мы подключаем рекомендованную фирмой 1С трансформацию adminstallrelogon.mst и пакет русского языка 1049.mst.
DESIGNERALLCLIENTS=1 – Важный момент! Это основные компоненты 1С:Предприятия, включая компоненты для администрирования, конфигуратор и толстый клиент. Без этого параметра ставится всегда только тонкий клиент, независимо от следующего параметра.
THICKCLIENT=1 – Толстый клиент.
THINCLIENTFILE=1 — Тонкий клиент, файловый вариант.
THINCLIENT=1 – Тонкий клиент.
WEBSERVEREXT=0 – Модули расширения WEB-сервера.
SERVER=0 – Сервер 1С:Предприятия.
CONFREPOSSERVER=0 – Сервер хранилища конфигураций.
CONVERTER77=0 – Конвертер баз 1С:Предприятия 7.7.
SERVERCLIENT=0 – Администрирование сервера.
LANGUAGES=RU – Язык установки – русский.

Дистирутив программы RunAsSpc содержит файл с названием runasspc.exe. Это и есть исполняемый файл, который будет открывать нужную нам программу с правами администратора. Информация, какую именно программу открывать, а также учётные данные администратора, содержатся в файле Crypt.spc. Разместим оба файла в сетевой папке.

В заключении создадим ещё один bat-файл, который мы разошлём пользователям. Запуская этот файл, пользователи установят себе на рабочий компьютер платформу 1С:Предприятие. Содержимое файла такое:

источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Автоматическое развертывание 1С:Предприятие в небольших сетях

Все новое — это хорошо забытое старое. В данном случае эта поговорка подходит как нельзя лучше. Методика автоматического развертывания программ пакета 1С:Предприятие по сети, она же «административная установка», известна давно и хорошо описана в документации, но почему-то довольно редко используется на практике. Возможно, имеет место некоторое «разделение труда», специалисты по 1С не занимаются установкой, а системные администраторы не читают документацию 1С. Поэтому будет не лишним еще раз вернуться к этому вопросу.

Данная методика рассчитана в первую очередь на небольшие сети без Active Directory и позволяет существенно облегчить работу системного администратора и повысить комфорт работы с системой 1С:Предприятие.

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

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

Вам потребуется только общая папка на файловом сервере, которая будет иметь следующую структуру:

Вам потребуется расположить в ней файл запуска 1С 1cestart.exe, желательно от последней версии платформы, его можно взять в C:\Program Files (x86)\1cv8\common. Конфигурационный файл 1cescmn.cfg со следующим содержимым:

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

  • DESIGNERALLCLIENTS — все клиенты и конфигуратор.
  • THINCLIENT — тонкий клиент для клиент-серверного варианта работы.
  • THINCLIENTFILE — тонкий клиент с возможностью работы с файловыми информационными базами.
  • SERVER — сервер 1С:Предприятия. Если программа установки запускается из программы запуска, то сервер будет установлен как приложение.
  • WEBSERVEREXT — компоненты расширения для веб-сервера.
  • CONFREPOSSERVER — сервер хранилища конфигураций.
  • SERVERCLIENT — компоненты для администрирования кластера серверов.
  • CONVERTER77 — конвертер информационных баз из версии 1С:Предприятия 7.7.
  • LANGUAGES — список языков интерфейса для установки. Если указано несколько языков, они перечисляются через запятую.
Читайте также:  Установка подрозетников под гипсокартон

Список общих баз, в нашем случае ibcommon.v8i, определяет перечень баз, которые будут подключены всем пользователям, это могут быть сетевые или клиент-серверный базы, обязательное условие — их доступность с любого ПК на которые будет устанавливаться платформа. Для его формирования можно воспользоваться файлом ibases.v8i, который расположен в %USERPROFILE%\AppData\Roaming\1C\1CEStart. Просто скопируйте оттуда необходимые секции.

Примерное содержимое файла:

В нашем случае указаны две базы: файловая по сети и серверная. Если вы использовали файл-источник с ПК где базы расположены локально, то просто замените их пути на сетевые, остальные настройки трогать не надо. Кроме параметра Version=8.3, с его помощью можно указать требуемую платформу для запуска, например, Version=8.3.11 означает, что база должна использовать последнюю доступную версию платформы 8.3.11, а Version=8.3.10.2252 — работать только с платформой 8.3.10.2252.

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

Общий ресурс готов, посмотрим, как это работает. Для первоначальной установки запустим файл 1cestart.exe с общего ресурса, это может сделать как администратор, так и сам пользователь. Это единственный раз, когда пользователю потребуется самостоятельно заходить на наш общий ресурс. Сразу после запуска начнется процесс установки платформы, который не задает вопросов и проходит полностью в автоматическом режиме.

При этом всегда устанавливается самая последняя доступная в общем каталоге версия платформы. Хорошо, но, если нам вдруг потребуется другая? Не проблема. Давайте укажем для одной из баз использовать только выпуск 8.3.11 и запустим ее.

Как видим, установка нужной платформы началась автоматически (при условии ее наличия на общем ресурсе).

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

Как видим, данный способ отлично подходит для использования в небольших сетях, избавляя администратора или специалиста по обслуживанию 1С от большого количества рутинной работы. Но есть и недостатки, один из них — наличие у пользователя прав для установки ПО, но в небольших сетях это, как правило, неактуально.

В крупных организациях с AD программное обеспечение разворачивается с помощью групповых политик и данная методика там просто не нужна. В тех случаях, когда пользователи без AD не имеют административных полномочий, для них следует включить политику Конфигурация пользователя — Административные шаблоны — Компоненты Windows — Установщик Windows — Всегда устанавливать с повышенными правами.

Если вам нужно несколько разных вариантов развертывания, то можно создать несколько ресурсов, со своим набором платформ, списков баз и настроек. Скажем один для работы, второй для разработчиков. Только желательно в этом случае также ограничить доступ к общим папкам, чтобы исключить случайную установку «чужой» платформы.

источник

Административная установка платформы “1С:Предприятие 8.2” при помощи групповой политики

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

При установке через групповые политики для указания языка установки нужно указывать соответствующий языковой файл трансформации. Имена файлов соответствуют десятичному представлению LCID Microsoft Windows (с расширением .mst). Файл трансформации для русского языка называется 1049.mst.
Кроме этого, дополнительно нужно указать файл трансформации adminstallrestart.mst. В этом случае система «1С:Предприятие» при несовпадении версий клиента и сервера будет предлагать перезагрузку компьютера для установки новой версии. Администратор должен позаботиться, чтобы новый дистрибутив уже был добавлен в групповых политиках.

Нужно создать общий каталог в вашей сети, где будут хранится установочные файлы. Проверить чтобы пользователи домена имели права чтения из этого каталога.
Открываем редактор GP. Создаем новую политику. Открываем её для редактирования. Переходим в раздел «Конфигурация компьютера» — «Установка программ». Пример показан на Windows Server 2008 R2.

Создаем новый пакет. Выбираем файл 1CEnterprise 8.2.msi, путь до файла необходимо указывать через сетевое окружение \\SRV\…..\1CEnterprise 8.2.msi, метод развертывания выбираем — особый, для того чтобы можно было внести модификации.

После создания пакета, у меня примерно 30 секунд, откроется окно свойств пакета.

Необходимо перейти на закладку «Модификации» и добавить файл трансформации для русского языка называется 1049.mst и файл трансформации adminstallrestart.mst. Должно получится так:

После того как нажмете «ОК» файлы модификации добавить будет не возможно.

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

источник

Бетке Сергей: iT блог

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 ):

Дам несколько пояснений. То, что мы пропишем в наименовании секции 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 создаём ярлык в меню пользователя.

Вот такая вот автоматизация.

Пишем плагин к wordpress по шагам

Отзывы » (37)

Добрый день, Сергей. Спасибо за статью. Я, вот, тоже посматриваю в сторону автоматизации установки 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 файлов обсуждать нет смысла — однозначно целесообразно!

Читайте также:  Установка гбо 2 поколения на карбюратор солекс

Интересный способ, надо будет потестировать.Я пробовал способ описанный в самой статье. Пробовал указывать не все записи, а только 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. Как то вообще не догадался об этом, хотели просто подменять клиентский файл, но вопрос возникал с «личными» базами. А теперь получается полностью управляемый вариант, и для пользователей пройдет незаметно любая миграция и изменения.

Да, именно эту цель и преследовал. Одна проблема — кириллицу использовать нельзя.

источник

Добавить комментарий