выполнить скрипт на всех компьютерах домена

Выполнить скрипт на всех компьютерах домена

Вот где я нашел сам скрипт для этого

круто. как вы его запускаете?

The opinion expressed by me is not an official position of Microsoft

3й раз написать вопрос?

The opinion expressed by me is not an official position of Microsoft

Я не понял суть вашего вопроса, подробнее сможете

вы в блокноте сохранили vbs, и сразу после этого у вас начинают спрашивать пароль? или может вы все таки еще что-то делаете?

Что такое сценарии запуска? Как вы его «туда» ставите? под какими пользователями выполняется скрипт? Логон скрипты? стартап скрипты?

я понял что вы нашли в сети скрипт его скачали и пытаетесь запустить но я не понимаю КАК вы это делаете

The opinion expressed by me is not an official position of Microsoft

При прямом запуске скрипта, он некоторые секунды скачивает в фоновом режиме файл ехе установочник с гитхаба, после скачки, скрипт хочет его установить и прописать туда адрес моей веб службы вот в этом моменте он запрашивает желтым UAC админский пароль

При прямом запуске скрипта, он некоторые секунды скачивает в фоновом режиме файл ехе установочник с гитхаба, после скачки, скрипт хочет его установить и прописать туда адрес моей веб службы вот в этом моменте он запрашивает желтым UAC админский пароль

1 (вопрос к первому абзацу) пользователь админ на той раб станции где запускаете скрипт руками?

2 (утверждение ко второму абзацу) Пользовательские политики выполняются в контексте пользователя и если он (пользователь) не админ то появление окна закономерно. Как решение можно пробовать впихнуть скрипт в контекст компьютера, в таком случае прав у пользователя System хватит

в теории возможны проблемы с загрузкой так как на момент старта системы интернета еще может не быть, но давайте решать вопросы постепенно

The opinion expressed by me is not an official position of Microsoft

Источник

PowerShell: используем Invoke-Command для запуска команд/скриптов на удаленных компьютерах

В этой статье мы рассмотрим особенности использования командлета Invoke-Command для удаленного выполнения команд и скриптов. Возможно запускать команды удаленно на одном компьютере, или параллельно на множестве компьютерах в вашей сети. Командлет Invoke-Command использует возможности удаленного управления, заложенные в PowerShell Remoting. PowerShell Remoting позволяет удаленно подключаться к PowerShell сессиям на компьютерах через службу WinRM (Windows Remote Management) через протокол Web Services for Management (WS-Management). Этот сервис дает возможность принимать команды Powershell и устанавливать сеансы.

Настройка WinRM для PowerShell Remoting

Для связи между компьютерами в PowerShell Remoting используется протокол HTTP (порт TCP/5985) или HTTPS (порт TCP/5986). По умолчанию используется протокол HTTP, но даже этот трафик шифруется с помощью ключа AES-256 (впрочем, есть угроза атак man-in-the middle). Возможна аутентификация через Kerberos (в домене) или NTLM.

На удаленных компьютерах, к которым вы планируете подключаться должен быть запущена служба WinRM. Проверить это можно так:

Если служба не запущена, запустите ее:

Данная команда запустит службу WinRM (установит автоматический запуск), выставит настройки winrm по-умолчанию и добавит исключение в Windows Firewall. Команда Enable-PSRemoting –Force включает WinRM без запроса пользователя.

Теперь к компьютеру можно подключиться удаленно через PowerShell Remoting.

Также нужно включить правило Window Defender Firewall, которое разрешает доступ к WinRM в общедоступных сетях. Вы можете включить правило брандмауэра с помощью GPO или PowerShell:

Чтобы проверить подключение к удаленному компьютер через PowerShell Remoting используется команда:

Если у вас нет домена, или вы обращаетесь к компьютерам через PowerShell Remoting по IP адресам, в этом случае используется для аутентификации используется протокол NTLM. При использовании NTLM, при выполнении команду Invoke-Command появится ошибка:

Для корректной работы NTLM аутентификации, на компьютере, с которого вы будете устанавливать подключения нужно выполнить дополнительные действия: выпустить SSL сертификат и исопльзовать его для шифрования HTTPS трафика winrm, или добавить имя/IP адрес хоста в доверенные:

Либо можно разрешить подключение ко все компьютерам (не рекомендуется, т.к. один из главных недостатков NTLM – он не осуществляет проверку подлинности).

Аналогичные настройки нужно сделать на удаленных хостах.

Чтобы вывести список доверенных хостов, выполните команду:

Чтобы применить изменения, перезапустите службу WinRM:

Удаленное выполнение PowerShell с помощью Invoke-Command

Командлет Invoke-Command позволяет выполнить команду на одном или нескольких удаленных компьютерах.

Например, для запуска одиночной команды на удаленном компьютере можно использовать такую команду:

По-умолчанию команда, посланная через Invoke-Command выполняется на удалённом компьютере от текущего пользователя. Если нужно выполнить команду от имени другого пользователя, сначала нужно запросить учетные данные пользователя и сохранить их в переменную:

Можно задать несколько команд в блоке ScriptBlock, их нужно разделить точкой с запятой. Например следующая команда выведет текущий часовой пояс и изменит его на другой:

Используем Invoke-Command для параллельного запуска команд на нескольких компьютерах

Командлет Invoke-Command можно использовать для параллельного выполнения команд на нескольких удаленных компьютерах.

В самом просто случае имена компьютеров, на которых нужно выполнить команды указываются через запятую:

Список компьютеров можно поместить в переменную (массив):

Или получить из текстового файла:

Также можно получить список компьютеров в ADс помощью командлета Get-ADComputer из модуля AD PowerShell:

Чтобы выполнить команду на всех Windows Server в домене, исопльзуйте такой код:

Если компьютер выключен, или недоступен, благодаря параметру SilentlyContinue скрипт не будет остановлен и продолжит выполнение на других компьютерах.

Чтобы понять с какого компьютера получены результаты, нужно использовать специальную переменную окружения PSComputerName.

При запуске команды через Invoke-Command на нескольких компьютерах она выполняется параллельно. В Invoke-Command есть ограничение на максимальное количество компьютеров, которыми можно управлять одновременно (ограничение на количество одновременных PSSession). Оно определяется параметром ThrottleLimit (по умолчанию 32). Если вам нужно выполнить команду одновременно более чем на 32 компьютерах (например, на 128), используйте параметр –ThrottleLimit 128 (но это вызывает повышенную нагрузку на ваш компьютер).

Если вы хотите запускать команды на удаленном компьютере интерактивно, используйте командлет Enter-PSSession.

Источник

Личные IT заметки

среда, 9 сентября 2015 г.

GPO AD: Computer Startup scripts and Powershell (часть 1: Создание.Запуск)

Не так часто мне удавалось видеть рабочую конфигурацию «Сценария запуска для компьютера» и уж тем более не доводилось реализовать. Но вот возникла необходимость. И казалось-бы у Miscrosoft в редакторе GPO имеются для этого комфортные средства. Бери и делай! Но что-то пошло не так. и мои скрипты не захотели работать. Поэтому здесь я опишу то, с чем мне пришлось столкнуться в процессе решения такой задачи.

Выбор расположения скриптов и права доступа

Мои скрипты расположены не только в папке политики, которая их и будет выполнять.

Один скрипт у меня находится: \\domen.local\SysVol\domen.local\Policies\\Machine\Scripts\Startup\Main.ps1

Второй скрипт вызывается из первого и у меня он находится: \\domen.local\NETLOGON\zabbix_install.ps1

В открывшемся окне перейти на вкладку Сценарии PowerShell и нажать внизу кнопку: Показать файлы

И это касается каждой папки, к которой планируется обращение от имени доменного компьютера.

Выбор скрипта для запуска и редактирование GPO

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

По большому счету все. НО! По умолчанию, ваши PS скрипты не будут запускаться даже из сети, основываясь на безопасности GPO.

Путей решения несколько. Разрешить запуск любых скриптов. Или использовать политику безопасности, которая позволит запускать скрипты, расположенные локально или в сети, но при этом скрипты должны быть подписаны.

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

По умолчанию она выключена, а это значит, что выполнение скриптов ЗАПРЕЩЕНО!

Для проверки текущей политики безопасности существует командлет:

Get-ExecutionPolicy

Restricted — блокируются любые скрипты.

AllSigned — разрешены только те, которые имеют цифровую подпись

Bypass — ничего не блокируется, никакие предупреждения и запросы не появляются.

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

Запуск скриптов в Windows Server 2012 R2 Windows 8.1 и выше

Чтобы это исправить необходимо скорректировать еще один пункт в политике безопасности.

На данный момент уровень моего домена и леса = 2012. Как и все контроллеры домена, под управлением Windows Server 2012. А в этих версиях отсутствует параметр управления этой задержкой. Поэтому первое, что необходимо сделать, это скачать административные шаблоны ADMX отсюда: http://www.microsoft.com/ru-ru/download/details.aspx?id=41193

Скачав файл Windows8.1-Server2012R2ADMX-RTM запустите его установку на одном из контроллеров домена. Путь по умолчанию будет: C:\Program Files (x86)\Microsoft Group Policy\Windows 8.1-Windows Server 2012 R2\PolicyDefinitions\ Зайдите в эту папку и удалите лишние языковые директории. Я оставил лишь en-US и ru-RU т.к. имею в распоряжении русскую и английскую версию оснастки.

Теперь необходимо создать Централизованное хранилище политик. На контроллере домена скопировать папку PolicyDefinitions целиком из %systemroot% в папку %systemroot%\sysvol\domain\policies\

Затем скопировать содержимое из папки C:\Program Files (x86)\Microsoft Group Policy\Windows 8.1-Windows Server 2012 R2\PolicyDefinitions\ в папку %systemroot%\sysvol\domain\policies\PolicyDefinitions\
В последствии эти шаблоны будут автоматически распространены и для других контроллеров домена. А вам необходимо только перезапустить оснастку редактора групповых политик.

Включаем этот параметр и выставляем значением «0 мин». Таким образом мы полностью отключаем задержку сценария входа.

Теперь наши скрипты будут также успешно работать и в Windows 2012 R2 и Windows 8.1 при загрузке компьютера!

Продолжение:

Также вы можете посмотреть мои обращения в Microsoft Technet, где мне успешно помогали решать эти задачи. За что коллегам отдельная благодарность!

Источник

Выполнить скрипт на всех компьютерах домена

Общие обсуждения

Необходимо запустить некую программу удаленно на компьютерах определенной OU в домене. В интернете нашел много примеров, но большинство не подходят, либо не работают. Из всего материала смог собрать кое что но не до конца.

# Получаем данные из определенной OU в каталоге AD

$ADList = (new-object System.DirectoryServices.DirectorySearcher([ADSI]»LDAP://ou=Workstation,dc=company,dc=domain,dc=local»,»(&(&(objectCategory=computer)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))))»)).findAll()

# Получаем список компьютеров

# Даём переменную для команды

$Command = «cmd.exe /c systeminfo.exe > \\serve\Users\%computername%.txt»

# А вот это мне необходимо закольцевать

Если последнюю строку оставить как есть, то в команду подставляется целый массив имен.

Все ответы

1) После выполнения команды для определенной машины, в окне консоли примерно это видно

__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 2
__DERIVATION : <>
__SERVER :
__NAMESPACE :
__PATH :
ProcessId : 3464
ReturnValue : 0

По диспетчеру задач во время исполнения cmd отсутствует

>По диспетчеру задач во время исполнения cmd отсутствует

ProcessId : 3464
ReturnValue : 0

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

>>ProcessId : 3464
>>ReturnValue : 0

На одной из машин проверил файрвалом, запрос через WMI создается, но cmd не стартует.

Запустил, через удаленную консоль (Dameware) команду cmd.exe /c systeminfo.exe > \\applic\Users\PublicNIS\%computername%.txt», от этого пользователя. Команда сработала. Через скрипт нет.

В библиотеке нашел данный скрипт для запуска cmd, объём кода впечатляет. Может его прикрутить? http://gallery.technet.microsoft.com/ScriptCenter/en-us/56962f03-0243-4c83-8cdd-88c37898ccc4

>ProcessId : 3464
>ReturnValue : 0

видоизмените скрипт следующим образом:

$Command = «cmd.exe / k systeminfo.exe > \\serve\Users\%computername%.txt»

([wmiclass]»\\ remote_computer_name \root\cimv2:Win32_Process»).create($Command)

запостите сюда результат ее работы (интересует ProcessId и ReturnValue), а затем покажите результат работы следующей команды:

PS C:\Users\2life> ([wmiclass]»\\pc1\root\cimv2:Win32_Process»).create($Command)

Источник

1000++ способ запуска команд на удаленном компьютере

В наше время даже для собак придумали удаленное управление.

Возвращаясь к циклу «Конспект Админа», мне хотелось бы рассказать о вариантах запуска исполняемых программ на удаленных компьютерах. Эта статья будет интересна тем, у кого еще нет систем централизованного управления, но уже есть понимание утомительности ручного обхода рабочих станций и серверов. Либо тем, кому решения «под ключ» не интересны ввиду неспортивности.

В качестве того, зачем нужен такой запуск программ, можно привести недавнюю истерию с Петей\Не-Петей, когда все бросились проверять\отключать SMBv1 и загружать обновления. Да и провести инвентаризацию или установить срочный патч таким методом тоже можно.

Когда-то давно я устроился работать в организацию в период эпидемии Kido\Conficker. Наиболее простым способом выяснить, все ли хорошо в ИС компании, была славная утилита от Касперского под названием Kido Killer, которая проверяла наличие вируса и устраняла его. Запускать программу на доброй сотне машин руками было невесело, поэтому пришлось знакомиться с автоматизацией.

Если в операционных системах *nix для удаленного запуска, как правило, используется SSH, то у Windows способов запуска программ и скриптов воистину как песка в пустыне. Я разберу основные варианты, как общеизвестные, так и экзотические. Таких очевидных вещей как telnet-сервер касаться не буду, тем более Microsoft уже убрала его из современных ОС.

Способы старые, временем проверенные

Psexec

Пожалуй, это первое, что приходит на ум, когда идет речь об удаленном запуске программ. Утилита от Марка Руссиновича используется еще со времен Windows NT и до сих пор применяется. Помимо основной функции, можно использовать ее и как Runas, и для запуска программ в пользовательской сессии терминального сервера. Psexec также позволяет задавать ядра процессора, на которых будет запускаться программа, и ее приоритет в системе.

В качестве примера посмотрим, установлено ли обновление, закрывающее нашумевшую уязвимость SMB на списке компьютеров:

В файле computers.txt находится список компьютеров. Для запуска по всему домену можно использовать \\*. В файле \\server\share\log.txt будут появляться имена рабочих станций или серверов без обновления. Если в домене существуют компьютеры с *nix на борту или нет доступа к административному сетевому ресурсу Admin$ ― команда на этой машине не выполнится, но обработка продолжится. Чтобы скрипт не зависал при каждой попытке подключения, можно задать тайм-аут с помощью ключа -n.

Если компьютер выключен ― мы об этом не узнаем. Поэтому лучше предварительно проверять доступность машин или собирать в файле информацию об успешном или неудачном выполнении.

К минусам Psexec можно отнести то, что она из-за своего удобства и популярности часто используется вирусописателями. Поэтому антивирусные системы могут обнаруживать утилиту как опасность вида remote admin.

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

Для управления системами Windows с помощью разных графических утилит часто используется WMI (Windows Management Instrumentation) ― реализация объектно-ориентированного стандарта управления WBEM. В качестве утилиты с графическим интерфейсом для работы с WMI можно использовать wbemtest.exe.

Для работы с WMI из консоли создана wmic.exe. Например, для проверки установленных обновлений вместо жутковатой конструкции из предыдущего примера можно использовать простую команду:

Использовать список компьютеров также можно командой /node:»@computers.txt».

Еще при помощи WMI можно запускать программы – синтаксис предельно прост:

К сожалению, в отличие от Psexec, получить вывод в консоли не получится ― придется выводить результаты команды в файл.

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

Групповые политики и скрипты

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

Скрипты, выполняющиеся при старте и завершении системы.

Скрипты, выполняющиеся при входе и выходе пользователя из системы.

Скрипты, настраиваемые в пользовательском разделе, выполняются от имени пользователя, а в разделе компьютера ― под аккаунтом SYSTEM.

Назначенные задания

Довольно интересный способ, заслуживающий право на жизнь. Назначенные задания можно создавать из командной строки при помощи утилиты schtasks.exe, выполнять их, затем удалять. Подробнее с синтаксисом можно ознакомиться в документации, я же разберу пример использования назначенных заданий в доменной среде. Предположим, нам нужно выполнить команду как можно быстрее вне зависимости от того, выключен компьютер или нет. Для этого используются так называемые предпочтения групповых политик (Group Policy Preference).

Искать установку назначенных заданий следует в конфигурации компьютера или пользователя ― «Настройка ― Параметры панели управления ― Назначенные задания».

Создание нового назначенного задания.

Для выполнения команды или скрипта ASAP понадобится создать «Немедленную задачу (Windows 7 и выше)». Если вдруг в инфраструктуре остались машины под управлением Windows XP, то подойдет «Очередное задание (Windows XP)».

Стоит сделать несколько политик с соответствующими WMI-фильтрами или создать два разных назначенных задания в одной политике с нацеливанием ― например, при помощи того же WMI-фильтра. Это поможет избежать конфликтов в разнородной среде со старыми и новыми Windows.

Пример WMI-фильтра для применения политики только на компьютерах с Windows XP:

В остальном процедура создания назначенного задания тривиальна. Единственное, не забывайте отметить пункт «Применить один раз и не применять повторно», если задача не требует повторного запуска.

Запускаем немедленную задачу только один раз.

При использовании таких назначенных заданий программа запустится, как только компьютер получит обновление групповой политики. Это удобно: не нужно проверять доступность компьютеров в случае Psexec и wmic и заставлять пользователей перезагружать машины, как в случае скриптов групповых политик. При необходимости можно скопировать файл скрипта локально в разделе «Настройка ― Конфигурация Windows ― Файлы».

Назначенные задания позволяют явно задать имя пользователя для запуска программы, в том числе и для SYSTEM.

Через реестр

Модификация реестра на пользовательских машинах ― странный вариант, лишь на случай крайней необходимости. Можно использовать ветки Run или RunOnce. Подробнее о них ― в документации. Сама модификация реестра может проводиться через групповые политики или из командной строки ― например, такой командой:

В зависимости от ветки реестра, процесс будет выполняться или под пользователем, выполнившим вход в систему, или под аккаунтом SYSTEM.

Есть и другие способы, такие как правка ярлыков в папке «Автозагрузка» или добавление в ярлык к популярной программе && script.cmd, но эти методы уже из серии «можно, но не нужно».

Теперь перейдем к новым инструментам.

Способы новые или куда же без PowerShell

PowerShell, оправдывая свое название, может подключаться к удаленным компьютерам при помощи WMI, RPC и WS-Management (WSMan). Использование последнего метода требует предварительной настройки.

Командлеты, не требующие предварительной настройки, как правило, имеют параметр ComputerName, но не имеют параметра Session. Посмотреть список таких командлетов можно командой:

Для настройки WSMan в общем случае достаточно выполнить команду Enable-PSRemoting-Force. Она запустит службу удаленного управления WinRM и пропишет исключения в фаерволе ― в принципе, это можно сделать для всего домена при помощи групповых политик. Подробнее настройка описана в документации.

После того как все компьютеры будут готовы принимать запросы, мы сможем подключаться при помощи соответствующих командлетов PowerShell. Для проверки возможности подключения используется командлет Test-WSMan.

Проверка возможности подключения.

Для того чтобы выполнить определенную команду или скрипт, используется командлет Invoke-Command со следующим синтаксисом:

Где COMPUTER ― имя компьютера, COMMAND ―– имя команды, а USERNAME ― имя пользователя, если оно нужно.

Смотрим содержимое диска С удаленного компьютера.

Если же нам нужно получить полноценную консоль ― не автоматизации ради, а ради управления конкретным компьютером, ― то можно использовать командлет Enter-PSSession.

Работаем в консоли удаленного компьютера.

Напомню, что с помощью JEA можно ограничить доступные подобной сессии командлеты или дать доступ нужным без прав администратора.

Конечно, кроме встроенных средств и небольших утилит, существует множество программ для управления структурой. Помимо взрослых решений, для управления конфигурациями вроде Chef, Ansible и MS SCCM можно использовать и средства мониторинга вроде Zabbix, и даже консоль управления антивирусом Касперского.

В период гетерогенных структур хорошо бы иметь возможность унифицированного управления Windows и Linux. Это можно сделать и с помощью PowerShell, что само по себе достойно отдельной статьи ― стоит такую сделать или уже лишнее?

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

Источник