Создание установочного пакета с PowerShell скриптом

[Dmitry T]

Задача. Распространить на доменные ПК PS-скрипт, добавляющий в локал. админы доменную группу (взято для примера, в скрипте важна работа в доменной (MS AD) среде) .

Решение: создал пакет с bat файлов и PS скриптом:

bat:

PowerShell.exe -ExecutionPolicy Bypass -File Script.ps1

Script.PS1:

$AdminGroup = "S-1-5-32-544"; $Member = "TEST\Admins";
if (Get-LocalGroupMember -SID $AdminGroup | Where-Object { $_.Name -eq $Member})
{}
else {Add-LocalGroupMember -SID $AdminGroup -Member $Member}

(скрипт не обязательно такой, взял для примера).

Вариант рабочий, при запуске из консоли cmd под локал. администратором.

Через KSC задача висит около 10 минут, заканчивается SUCCESS но скрипт не отрабатывает. Что нужно сделать, чтобы запустить скрипт?

 

[Demiad]

@Dmitry T, добрый день

Скрипт на ПК через задачу запускается от Local System Account. А проверяете Вы, вероятно, под доменной учётной записью. Под локальной учётной записью требуется авторизация в домене для добавления уч.записи в группу Администраторы.

[Dmitry T]

To Demaid.

Здравствуйте, спасибо за ответ. А как в таком запускать PS скрипты, требующие чтение AD? Это ведь распространенная задача.

Где-то читал решение (вероятно Ваш совет) через запуск task шедулера из-под доменной УЗ, являющейся локальным администратором. Но это ведь небезопасно плюс костыль. Есть ли более простой способ работы с AD через PS скрипты штатными средствами KSC?

[Roman Andreev]

Такая задача решается не через KSC. Для этого есть групповые политики.

[Dmitry T]

Roman,

согласен, есть и GPO и SCCM и прочие Manage Engine... Но если в KSC заявлен функционал, который доступен только при покупке лицензии "Системное администрирование", и люди купили этот функционал, то почему нельзя сделать такую элементарную вещь как задеплоить скрипты PS, работающие в доменной инфраструктуре. Может этот вопрос переправить к разработчикам, чтобы они "допилили" функционал и позволяли запуск скриптов, хотя бы как runas, а не только как LocalSystem? Пишу это, потому как рассматриваем переход с другого продукта, на KSC по известным причинам.

[Demiad]

@Dmitry T, KSC не является SCCM и не реализует функции GPO. Что заложено в функционал "Системное администрирование" изложено в справке продукта, конкретно на странице https://support.kaspersky.ru/ksc/14.2/209155

Я могу дать вам вредный совет добавить в скрипт доменный пароль. Но так делать рискованно, скрипт лежит в доступной всем пользователям домена папке \\ksc\klshare в явном виде. И в целом если устройства входят в Windows-домен, зачем применять KSC?