Меню Рубрики

Установка программ для пользователя в домене

Автоматическая установка программ в домене Windows

Автор

Вступление

Если в домене Windows установлен WSUS, админ рад и спокоен — дескать, все, обновления ставятся на автомате, трафик снизился, бегать по компам не надо и пр. В принципе, все осталость то же самое, но ведь не все используют в работе Microsoft Outlook или Internet Explorer (хотя 8-ка очень неплоха). Есть много людей, привыкших работать с почтовиком The Bat!, броузером Opera или Mozilla. Если встает вопрос об обновлениях — либо это головняк админу в виде беготни к каждому компьютеру для обновления всем, скажем, Opera, либо юзеры должны сидеть под админами (пускай и локальными, не доменными).

Естественно, ни первый, ни второй способы — не выход. Значит, надо иметь возможность автоматически устанавливать программы на рабочих станциях, причем желательно делать это до того, как пользователь вошел в систему — ведь если он вошел, он уже не захочет перезагружать машину и т.п. Надо ставить пользователя перед фактом — программа, его любимая Opera, уже обновлена и админа не колбасит, что версия 10.10 почему-то нравится меньше, чем предыдущая. Просто вышло обновление, и его надо применить. Без вариантов.

Самый распространенный вариант ответа на вопрос — КАК? — Конечно, через Active Directory! — скажет вам любой специалист или просто сисадмин. А как через AD? — спросите вы. А вам скажут — ?! Вы не знаете, как через AD? Да там же просто, через policy! — но больше вам скорее сего ничего не скажут, потому что для большинства советчиков этот вопрос такой же неясный, как и для вас. И вам ничего не останется, как гуглить до потери пульса, потому что найти огромный фолиант на тему «как развернуть office 2007» в сети корпорации не проблема, а вот просто и в двух словах — редко что найдете. Не без гордости могу сказать, что данная статья как раз одна из немногих кратких и «без наворотов», попадавшихся мне.

Установка программ из MSI

Все изложенное далее относится к работе с инсталляционными пакетами типа MSI (расширение .msi). Файлы MSI есть (или их можно извлечь) для многих программ (Adobe Acrobat, The Bat, Opera, Firefox и пр.).

Предположим, мы хотим автоматически установить (а по мере выхода обновлений, устанавливать обновления) броузер Firefox. Файл msi для Firefox можно взять здесь (в новом окне).

Настройку шаблона .adm я пропущу, т.к. далеко не всегда это нужно, а еще чаще этот шаблон фиг найдешь. В итоге — дефолтные настройки (либо, если будем ставить поверх старой версии — настройки будут сохранены). Шаблон .adm нам не нужен.

Распределяем права доступа

Предполагаю, что все учетные записи компьютеров (кроме контроллеров домена) находятся в OU «OU Office Computers».

Примечание 1:

Почему лучше не использовать исходное размещение компьютеров (Computers — Компьютеры домена в оснастке Active Directory Users and Computers)? Мне удобнее в дальнейшем управлять политиками для групп компьютеров. К тому же, когда я посещал курсы Microsoft, я видел, что на контроллерах доменов в тестовых системах и в «боевых», настроенных специалистами Microsoft, используются практически только отдельно созданные OU, а не базовые. Я для себя решил повторять опыт специалистов. Пока мне от этого только удобнее. Естественно, ИМХО.

Примечание 2:

Не всем пользователям нужен Firefox (как не всем нужен The Bat, Opera и пр.). Поэтому создадим в «OU Office Computers» отдельную группу компьютеров, на которые будет установлен Firefox. Для ясности назовем группу GFirefoxComputers. Отмечу, что это будет именно группа, а не вложенное OU!

Расшариваем какую-либо папку на сервере (на рисунке это SoftwareDistibution, а не Mozilla Firefox, как может показаться) и даем группе GFirefoxComputers доступ на чтение, админу — полный доступ (не компьютеру админа, а пользователю — все-таки вы должны иметь возможность по сети заливать на шару файлы ;)).

Вообще, для проверки того, как все вообще работает, можно обойтись и без группы GFirefoxComputers. Просто для того, чтобы сразу не усложнять себе жизнь, и не пенять на групповые политики, если что пойдет не так 😉

Политика правит миром!

На контроллере домена запускаем редактор групповой политики GPMC.MSC:

Читайте также:  Установка проигрывателя dvd на компьютере

. и создаем связанную только с нашим OU «OU Office Computers» групповую политику под названием «Firefox 3.6.3 rus»:

. редактируем нашу политику «Firefox 3.6.3 rus»:

Готовим дистрибутив Firefox для развертывания в сети

В разделе «User Configuration» -> «Software settings» -> «Software Installation» щелкаем правой мышкой и создаем новый объект для установки — наш будущий инсталлятор Firefox.

Выбираем файл MSI, заботливо положенного чьими-то руками в расшаренную папку. Важно : выбирать надо сетевой путь до файла, а не локальный, ведь юзера будут получать доступ к вашей инсталляшке не локально на сервере, а по сети.

Выбираем «Assigned» (Назначенный):

На этом работа с веткой «Software Installation» закончена.

Закрываем все открытые окна на сервере (если не помешает другим задачам, естественно), Пуск -> Выполнить -> gpupdate /force

Установка на рабочих станциях

Далее достаточно просто перезагрузить рабочие станции, чтобы автоматически установился Firefox ДО того, как появится окно для ввода логина/пароля. Иными словами, пользователь будет не в силах чего-то не установить, забыть и пр. Поэтому этот способ так хорош. Вы удаленно решаете, что будет установлено / обновлено на рабочих станциях.

Windows XP бывает не с первой перезагрузки «принимает» нове политики, поэтому можно подойти к юзеру, выполнить команду «gpupdate /force» (не обязательно под админом) и перезагрузить его компьютер.

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

Дополнительно

Теперь на любой новый компьютер, введенный в состав подразделения OU Office Computers будет установлена последняя версия броузера Firefox. Вам даже не придется ничего делать. Просто и очень полезно. Таким же образом можно устанавливать практически любой софт, включая Adobe Reader, Adobe Flash Player (которые в обычной ситуации требуют административных прав для установки), The Bat. да мало ли софта у вас в локальной сети, поддерживать который в актуальном состоянии одна из обязанностей системного администратора.

Нюанс: если вы уже установили какой-либо пакет, в нашем случае Firefox 3.6.3 rus, а через некоторое время вам потребуется его обновить (т.к. рано или поздно выйдет новая версия броузера), сначала удалите политику по установке Firefox 3.6.3, после чего создайте новую. Потом «gpudate /force» и вперед!

источник

Установка программ для пользователя в домене

Вопрос

Все пользователи в домене входят в группу пользователи домена. 2-3-м пользователям переодически необходимо устанавливать программы (где-то 1 раз в месяц) на 3-4 компьютерах. Каким простым образом можно давать им это право на 2-3 дня а потом отбирать? Можно создать отдельную учетку с правами админа, но давать парва адина даже на время нет желания. Добавлять этого пользователя на каждом компьютере в группу Опытных пользователей или Администраторов, тоже нет желания.

Ответы

Можно создать группу в AD. Дать ей необходимые права на компьютерах пользователей и при необходимости включать\исключать из неё пользователей. Также можно попробовать распространять ПО при помощи групповых политик (это более трудоемкий вариант, но зато более контролируемый).

Я бы создал дополнительную учетную запись в Active Directory LocalInstallUser , череp GPO Restricted Groups включил бы этого пользователя в нужные локальные группы на необходимых компьютерах.

С войствах учетной записи можно можно задавать жизнь учетной записи (Вкладка Account ) Account Expire. Тут можно будет задавать время работы учетной записи.

Дать пользователям скрипты для установки программ:
к примеру: install.bat
runas /user:Domain_name\LocalInstallUser «setup.exe»

Научил бы пользователей запускать вместо привычного Setup.exe , необходимость запускать Install.bat
Он затребует пароль на новую учетку и запустит установку от его имени.

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

Если сообщение было информативным, отметьте его как правильный ответ. Сразу видно ответ на вопрос 🙂

Все ответы

Можно создать группу в AD. Дать ей необходимые права на компьютерах пользователей и при необходимости включать\исключать из неё пользователей. Также можно попробовать распространять ПО при помощи групповых политик (это более трудоемкий вариант, но зато более контролируемый).

Я бы создал дополнительную учетную запись в Active Directory LocalInstallUser , череp GPO Restricted Groups включил бы этого пользователя в нужные локальные группы на необходимых компьютерах.

Читайте также:  Установки для алмазного бурения shibuya

С войствах учетной записи можно можно задавать жизнь учетной записи (Вкладка Account ) Account Expire. Тут можно будет задавать время работы учетной записи.

Дать пользователям скрипты для установки программ:
к примеру: install.bat
runas /user:Domain_name\LocalInstallUser «setup.exe»

Научил бы пользователей запускать вместо привычного Setup.exe , необходимость запускать Install.bat
Он затребует пароль на новую учетку и запустит установку от его имени.

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

Если сообщение было информативным, отметьте его как правильный ответ. Сразу видно ответ на вопрос 🙂

Есть два типа:

  1. Полностью замещает в членов в группе
  2. Добавляет новых членов в группу

Для управления:

  1. Идем в GPO — Computer Configuration — Polices — Security Settings — Restricted Groups
  2. Добавлям новую группу и выбираем ту AD группу или пользователя, которую нам нем добавить в локальную группу. Т.е. к выбираем к примеру G_LocalSubAdmin .
  3. В свойствах есть два типа
  • Members of this group — Замещает всех членов в выбранной группе
  • This group is member of — Только добавляет, никого не трогая из уже присутствующих. Именно сюда мы добавляем нужную нам группу например локальных администраторов, имеющих SID S-1-5-32-544.

Возможно поможет использование Well-Known SID для добавления пользователей

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

источник

Установка программ на удаленных компьютерах в домене через active directory

Active Directory: установка программ пользователями
Здравствуйте, очень интересует один вопрос: Надо разрешить некоторым пользователям установку.

Поиск по имени компьютера в Active Directory (домене)
Всем доброго дня! Искал по интернету — не нашел, подскажите, может кто с AD через vb.net имел.

Закрывается explorer сам по себе. У всех компьютеров в домене Active Directory
Добрый день. В локальной сети по какой-то причине начал сам по себе закрываться explorer на всех.

Установка 1с на удаленных компьютерах
Всем привет, возникла необходимость на ноутбуках обновлять платформу 1с удаленно. bat файл по.

Конфигурация компьютера — Политики — Конфигурация программ — Назначенные приложения

Пишут, что такое сообщение возникает, когда через одну политику устанавливают несколько msi-пакетов. Но при этом, всё в конце-концов устанавливается.

Понятно, что не кофеварке

Т.е. установка должна происходить до входа пользователя в систему, т.е. в момент загрузки ОС и до того, как появится предложение ввести логин/пароль. А поэтому ещё раз, в какой момент вы видите это окно?

Вы же видите в журнале Windows событие о попытке начать установку этого msi, а значит с доступом к политике проблем нет.

Дальше вам нужно разбираться с каждым конкретным msi отдельно. Приведу два примера из своей практики:

1. Установка через GP — MS Lync клиента. В дистрибутиве есть setup.exe и msi. Добавляю msi в политику, проверяю журнал — установка начинается и завершается ошибкой. Внимательней читаю документацию и оказывается, что в msi специально добавлен параметр, который разрешает запуск только через setup.exe, т.к. в этом setup.exe происходит предварительная проверка условий (нужная версия .net и т.п.) перед запуском msi-установщика. Отключаю через Orca эту msi настройку и установка через политику начинает работать.

2. Всеми любимый 1С-клиент (8.3). Если просто указать msi в политике, установка будет заканчиваться ошибкой, т.к. помимо msi необходимо добавить модификацию (mst-файл) с нужным языком.

Естественно там где запускается msi, т.е. на локальном.

Вы же сами показывали запись из журнала:

Ну, после того как поставил галочку (кстати — спасибо!) «не использовать языковые установки при развертывании» записей на подобную тему исчезли.

Добавлено через 3 минуты
Вот такое пишут: «Не удалось применить изменения для параметров установки приложения. Установка программ, развертывание которых осуществляется через групповую политику для этого пользователя, отложено до следующего входа в систему, поскольку изменения должны быть применены до Ошибка: %%1274»

Читайте также:  Установка биксенона на ниссан патфайндер

Клиентскому расширению «Software Installation» групповой политики не удалось применить один или несколько параметров, поскольку эти изменения должны обрабатываться до запуска системы или до входа пользователя. Завершение обработки групповой политики будет выполнено перед следующим запуском системы или входом этого пользователя, что может вызвать замедление загрузки и запуска системы.

Во! ещё. «Не удалось назначить приложение Mozilla Firefox (en-CA) из политики Firefox. Ошибка: %%1274»
а потом — «Не удалось удалить назначение приложения Mozilla Firefox (en-CA) из политики Firefox. Ошибка: %%2»

источник

Удалённая установка приложений

Предлагаю программу для администраторов — Rinstall (скачать можно здесь). Она решает следующие задачи:

  1. Удалённое администрирование
  2. Удалённое выполнение команд
  3. Удалённая установка приложений

Фактически она является удобной графической оболочкой для утилиты psexec. Окно программы разделено на соответствующие этим трём задачам группы полей и кнопок:

  1. Host — IP-адрес/имя удалённого компьютера. Программа постоянно пытается подключиться к нему и сигнализирует о результате:
    • красный — компьютер не найден (возможно на нём включен брандмауэр);
    • жёлтый — компьютер найден, но учётные данные не верны / не хватает прав / на удалённом ПК включен «простой общий доступ к файлам»;
    • зелёный — компьютер найден, учётные данные верны, права есть.

    Здесь же можно указать список компьютеров. Для этого дважды щелкните в пустом поле — появится имя списка по умолчанию — list. Отредактировать список можно дважды щёлкнув по нему мышкой. Списков может быть несколько, но все они должны начинаться с символа «@«.

  • User — имя учётной записи для подключения к удалённому компьютеру.
  • Pass — пароль учётной записи для подключения к удалённому компьютеру.
    Дважды щёлкнув здесь, можно получить пароль LAPS — он будет скопирован в буфер обмена.
  • Во время подключения/установки выполняется перебор учётных данных, указанных в настройках программы, а также заданных в полях User и Pass.

    Настройки программы читаются при её запуске из файла rinstall.ini, который может находиться в каталогах «%PROGRAMFILES%\Rinstall\» и «%USERPROFILE%\Rinstall\» (последний приоритетнее).

    1. Удалённое администрирование

    1. [Info] — получить информацию о системе.
    2. [Soft] — получить список установленного ПО.
    3. [CM] — запустить консоль управления компьютером.
    4. [CMD] — запустить удалённый шелл.
    5. [CMRC] — подключиться через клиента Configuration Manager.
    6. [RDP] — подключиться через удалённый рабочий стол.
    7. [RA] — подключиться через удалённый помощник.
    8. [VNC] — подключиться через TightVNC (Ctr+Alt+Shift+T — панель инструментов).
    9. [Radmin] — подключиться через Radmin.
    10. [Resource] — открыть удалённый ресурс.
    11. [Space] — посмотреть, чем занято место на дисках удалённого компьютера.

    2. Удалённое выполнение команд

    1. [Command] — команда (запускаемый файл: *.exe,*.bat, *.cmd, *.vbs, *.hta, и т.д.), выполняемая на удалённом компьютере. По умолчанию указана команда запуска диспетчера устройств.
    2. [Args] — Аргументы (параметры/ключи) команды, если они нужны.
    3. [x] Copy — копировать команду на удалённый компьютер (при этом нужно указать её полный путь на локальном компьютере).
    4. [x] Hide — выполнить команду скрытно.
    5. [x] Wait — ждать завершения команды.
    6. [Far] — запустить Far.
    7. [CMD] — запустить шелл.
    8. [Autoruns] — запустить менеджер автозагрузки.
    9. [Geek Uninstaller] — запустить менеджер деинсталляции.
    10. [GPUpdate] — обновить групповые политики (с ключом /FORCE).
    11. [Reset] — завершить все psexec-процессы.
    12. [Renew] — обновить IP-адрес.
    13. [Reboot] — перезагрузить компьютер.
    14. [RunAsLnk] — создать ярлык для приложения, запускающегося от имени пользователя с правами администратора (используется бесплатная версия RunAsSpc).

    Команды выполняются на удалённом компьютере с правами SYSTEM.

    В качестве команд удобно запускать портативные приложения (не забываем ставить галочку Copy). Тут, правда, имеются непонятные проблемы с запуском SFX-архивов на удалённых компьютерах с 64-разрядной ОС…

    3. Удалённая установка приложений

    Папки с приложениями (Rel Path) размещаются внутри базового сетевого ресурса (Net Path). Доступ к нему осуществляется по учётным данным (Net User, Net Pass). Во время установки приложения на удалённом компьютере подключается сетевой диск (Net Disk).

    Требования к устанавливаемым приложениям:

    1. Приложение должно находиться в отдельной папке и ставиться автоматически.
    2. Папка приложения должна быть написана латинским алфавитом.
    3. Внутри папки приложения должен находиться файл install.bat, который
      устанавливает приложение. Желательно также, чтобы этот файл поддерживал
      ключ -u (деинсталляцию приложения).

    Всем этим требованиям соответствуют мои пакеты тихой установки.

    источник

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

    Adblock
    detector