Как запустить PowerShell script при запуске компьютера? Windows powershell открывается автоматически

powershell - Как запустить PowerShell script при запуске компьютера?

Наконец-то я получил PowerShell script для автоматического запуска при каждом запуске. Вам нужно будет создать два файла: первый - это Powershell script (например, script.ps1), а второй - файл .cmd, который будет содержать команды, которые будут выполняться в командной строке (например, startup.cmd).

Второй файл - это то, что нужно выполнить при запуске компьютера и просто скопировать в .ps1 в папку автозагрузки, не будет работать, потому что это фактически не выполняет script - он открывается только файл с помощью Блокнота. Вам нужно выполнить .cmd, который сам выполнит .ps1, используя PowerShell. Хорошо, достаточно лепет и шаг за шагом:

Создайте свой .ps1 script и поместите его в папку. Я поставил его на свой рабочий стол для простоты. Путь будет выглядеть примерно так:

C:\Users\< имя_пользователя > \Рабочий стол \ script.ps1

Создайте файл .cmd и поместите его в

C:\Users\< имя_пользователя > \AppData\Роуминг\Microsoft\Windows\Start Menu\Programs\Startup\ startup.cmd

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

Откройте файл .cmd с помощью текстового редактора и введите следующие строки:

PowerShell -Command "Set-ExecutionPolicy Unrestricted" >> "%TEMP%\StartupLog.txt" 2>&1 PowerShell C:\Users\<user_name>\Desktop\script.ps1 >> "%TEMP%\StartupLog.txt" 2>&1

Это будет делать две вещи:

Установите политику выполнения вашего PowerShell неограниченно. Это необходимо для запуска скриптов, иначе PowerShell этого не сделает.
Используйте PowerShell для запуска .ps1 script, найденного в указанном пути.

Этот код предназначен специально для PowerShell v1.0. Если вы используете PowerShell v2.0, это может быть немного иначе. В любом случае, проверьте этот источник для кода .cmd.

Сохранить файл .cmd

Теперь, когда у вас есть ваши файлы .ps1 и .cmd в их соответствующих путях и с script для каждого, вы все настроены.

qaru.site

Запуск PowerShell скриптов по расписанию

В задачи практически любого системного администратора входит написание различных скриптов и их запуск. Запланировать запуск скрипта по расписанию с помощью Task Sheduler — задача несложная, но при использовании PowerShell есть некоторые нюансы, о которых я расскажу в этой статье.

Итак, предположим, у меня есть скрипт start.ps1, который мне необходимо запускать ежедневно в течении 10 дней. Есть два способа решить эту задачу.

Способ 1

Для запуска скрипта воспользуемся оснасткой Task Scheduler, он же планировщик заданий. Найти его можно в разделе Administrative Tools, либо нажав Win+R и введя команду taskschd.msc. Открываем планировщик и в разделе Actions выбираем пункт Create Task.

На вкладке General указываем имя и описание задания, а также (по необходимости) пользователя, от имени которого задание будет запускаться. Для того, чтобы задание выполнялось вне зависимости от того, залогинен ли пользователь в системе, выбираем опцию «Run whether user is logged on or not». Если для выполнения задания требуется повышение привилегий, то отмечаем опцию «Run with highest privileges».

Далее идем на вкладку Triggers и создаем новый триггер, в котором будет храниться расписание запуска нашего задания. В поле Start указываем дату и время запуска, а в поле Expire — дату и время завершения задания. Указываем выполнять задание ежедневно (Daily) и задаем период повтора (Recur every) 1 день.

Примечание. Если вы хотите запускать задание чаще, чем раз в день, то надо выбрать одноразовое выполнение (One time), а в разделе Advanced settings отметить пункт Repeat task every и указать время повторения, минимум 5 минут, максимум 1 час. Если этого недостаточно, то дополнительно в поле Delay task for up to можно указать временную задержку.

И основное. Переходим на вкладку Action и указываем действие для запланированного задания. Напомню, что в целях безопасности PowerShell скрипты могут выполняться только интерактивно, то есть сначала надо запустить оболочку PowerShell и уже в ней указать путь к скрипту. Поэтому в поле «Action» указываем запуск powershell.exe, а в поле «Add Arguments» параметр -File и путь к нашему скрипту, вот так:

-File ″C:\Scripts\start.ps1″

Также в поле аргументы можно указать:

-Command — выполняет указанные команды и любые другие параметры. Этот параметр тоже можно использовать для запуска скрипта, например: -Command ″& {C:\Scripts\start.ps1}″. Кроме того, с его помощью можно передавать в скрипт параметры: -Command ″& {C:\Scripts\start.ps1 -a 1 -b 3}″;-ExecutionPolicy — задает политику выполнения скриптов для текущего сеанса, может принимать значения Unrestricted, RemoteSigned, AllSigned и Restricted. Заданная политика будет действовать только в текущем сеансе и имеет приоритет над любыми ранее созданными политиками;-NonInteractive — отключить вывод интерактивных запросов к пользователю;-WindowStyle Hidden — запуск окна PowerShell в скрытом режиме, незаметно для пользователя;-NoProfile — предотвращает загрузку профиля, что может несколько ускорить выполнение скрипта;-NoExit — оставить оболочку открытой после отработки скрипта. Это может понадобиться при проверке и отладке скрипта.

Заполнив необходимые поля жмем ОК и сохраняем задание. Теперь скрипт будет запускаться по расписанию ежедневно в заданное время в течении 10 дней.

Способ 2

В PowerShell 3.0 появился новый функционал Sheduled Job, дающий возможность создавать запланированные задания прямо из консоли, не пользуясь оснасткой планировщика. Воспользуемся им для планового запуска нашего скрипта.

Сначала создаем расписание запуска (ежедневно в полпятого вечера, в течении 10 дней):

$t = New-JobTrigger -Daily -At 4:30PM -DaysInterval 10

Затем сохраняем в переменной учетные данные:

$cred = Get-Credential contoso\administrator

В качестве опции указываем запуск задания с повышенными привилегиями:

$o = New-ScheduledJobOption -RunElevated

И регистрируем задание с именем Start:

Чтобы убедится в том, что задание создано, можно открыть планировщик и найти наше задание в разделе Microsoft\Windows\PowerShell\SheduledJobs.

Примечание. Для каждого запланированного задания PowerShell в директории %systemdrive%\Users\%username%\AppData\Local\Microsoft\Windows\PowerShell\ScheduledJobs создается одноименная папка. В этой папке находится само задание в XML-файле и папка Output, в которой, в подпапках по времени выполнения, хранится история выполнения задания — результат выполнения (файлs Result.xml) и статус задания (Status.xml). Эти файлы могут пригодиться для отладки и диагностики в том случае, если задание не отрабатывает должным образом.

Execution Policy

В заключение напомню об одном немаловажном моменте, а именно о политике выполнения скриптов Execution Policy. Посмотреть текущее значение политики можно командой Get-ExecutionPolicy. Политика выполнения может иметь значения:

• Restricted — блокируется выполнение любых скриптов. Значение по умолчанию;• AllSigned — разрешено выполнение скриптов, имеющих цифровую подпись;• RemoteSigned — скрипты, подготовленные на локальном компьютере, можно запускать без ограничений, скрипты, загруженные из Интернета — только при наличии цифровой подписи;• Unrestricted — разрешено выполнение любых скриптов. При запуске неподписанного скрипта, который был загружен из Интернета, программа может потребовать подтверждение;• Bypass — ничего не блокируется, никакие предупреждения и запросы не появляются.

Обычно для безпроблемного выполнения скриптов достаточно задать значение RemoteSigned. Изменить текущее значение можно командой Set-ExecutionPolicy, например:

Set-ExecutionPolicy RemoteSigned -force

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

windowsnotes.ru

Запуск командлетов AppFabric

Эта документация перемещена в архив и не поддерживается.

В этом разделе описаны способы запуска сеанса консоли AppFabric Windows PowerShell, импорта модуля AppFabric для Windows PowerShell и получения справки по командлетам AppFabric.

Командлеты AppFabric можно выполнять из командной строки в сеансе Windows PowerShell, если в общий сеанс Windows PowerShell был загружен модуль AppFabric Windows PowerShell (модуль сервера приложений ApplicationServer). Модуль ApplicationServer автоматически импортируется при выполнении команды Модули Windows PowerShell из группы "Администрирование". Модуль ApplicationServer не загружается автоматически при открытии модуля Windows PowerShell с помощью значка на панели инструментов или при выполнении команды powershell.exe. В таких случаях необходимо импортировать модуль вручную следующим образом. При этом модуль загружается только для текущего сеанса.

В Windows PowerShell есть встроенные функции отображения справки в командной строке. Для доступа к этим функциям можно использовать командлет Get-Help или псевдоним "Help". По умолчанию командлет Get-Help возвращает базовое описание функций и синтаксиса командлета. Можно добавить к командлету параметр –detailed или –full, чтобы получить более подробные или полные сведения о параметрах и других элементах этого командлета. Псевдоним "Help" позволяет отображать сведения, возвращенные командлетом Get-Help, постранично. Можно также отобразить список командлетов AppFabric для Windows PowerShell или вывести обобщенную справку для командлетов AppFabric. Для этого выполните следующие действия.

Открытие модуля AppFabric для Windows PowerShell

Чтобы открыть консоль PowerShell с автоматически загруженными модулями AppFabric, нажмите кнопку Пуск, перейдите в пункт Администрирование и нажмите пункт Модули Windows PowerShell.
Примечание
Команда Модули Windows PowerShell автоматически загружает модули ApplicationServer, DistributedCacheAdministration и DistributedCacheConfiguration.

Чтобы открыть консоль PowerShell с автоматически загруженным модулем DistributedCacheAdministration, нажмите кнопку Пуск и последовательно выберите пункты Windows Server AppFabric и Администрирование кэша Windows PowerShell.

Примечание

Команда Администрирование кэша Windows PowerShell автоматически загружает модуль DistributedCacheAdministration, но не загружает автоматически модули ApplicationServer и DistributedCacheConfiguration.

Примечание

При открытии консоли Windows PowerShell способами, отличными от использования команды Модули Windows PowerShell в меню «Администрирование», потребуется импортировать модули AppFabric (см. ниже). К этим способам относятся: команда "Windows PowerShell" в меню "Стандартные", значок "Windows PowerShell" на панели инструментов или выполнение программы powershell.exe в каталоге <диск>:\Windows\System32\WindowsPowerShell\v1.0. Модули AppFabric придется импортировать отдельно, поскольку эти способы не загружают модуль AppFabric ApplicationServer и другие модули автоматически.

Импорт модуля AppFabric для Windows PowerShell

При открытии консоли Windows PowerShell способами, отличными от использования команды Модули Windows PowerShell в меню "Администрирование", потребуется отдельно импортировать модули AppFabric.

В командной строке Windows PowerShell введите одну или несколько следующих команд и нажмите клавишу ВВОД: Import-Module ApplicationServer, Import-Module distributedcacheconfiguration и Import-Module distributedcacheadministration.

Примечание

Можно импортировать модуль ApplicationServer для Windows PowerShell, не являясь администратором компьютера.

Примечание

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

Примечание

Чтобы убедиться в том, что модуль ApplicationServer для Windows PowerShell загружен, в командной строке Windows PowerShell введите одну из следующих команд и нажмите клавишу ВВОД: Get-Command –module ApplicationServer, Get-Command –module distributedcacheconfiguration и Get-Command –module distributedcacheadministration. Должен отобразиться список командлетов AppFabric.

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

Для получения справки по определенному командлету в командной строке Windows PowerShell введите следующую команду и нажмите клавишу ВВОД: Get-Help <имя командлета> [-detailed | -full].

Примечание

Например, для отображения полной справки по командлету Get-ServiceInstance в командной строке Windows PowerShell введите следующую команду и нажмите клавишу ВВОД: Get-Help Get-ServiceInstance –full.

Для отображения на экране списка командлетов, содержащихся в модуле ApplicationServer, в командной строке Windows PowerShell введите следующую команду и нажмите клавишу ВВОД: Get-Command –module ApplicationServer.
Для вывода в файл списка всех командлетов, содержащихся в модуле ApplicationServer, в командной строке Windows PowerShell введите следующую команду и нажмите клавишу ВВОД: Get-Command –module ApplicationServer | Sort-Object > C:\AppFabricCmdlets.txt.

Для печати ссылки на все файлы справки по командлетам, содержащимся в модуле ApplicationServer, в командной строке Windows PowerShell введите следующую команду и нажмите клавишу ВВОД: Get-Command –module ApplicationServer | Sort-Object Verb,Noun | Get-Help -detailed > C:\HelpTopicsSortedNounVerb.txt.

2011-12-05

msdn.microsoft.com

Управляем службами Windows с помощью PowerShell. Часть 2 / Блог компании Netwrix / Хабрахабр

Продолжаем знакомиться с тем, как осуществлять управление службами Windows с использованием PowerShell. В предыдущем посте мы рассмотрели, как получить статус службы на локальном и удаленном компьютере, произвести фильтрацию служб (например, найти только остановленные службы) и определить зависимые службы. В этом посте будут рассмотрены такие достаточно тривиальные вещи, как:

Остановка службы
Запуск службы
Перезапуск службы
Приостановка и возобновление работы
Управление удаленными службами
Настраиваем автозагрузку службы

Мы уделим большее внимание разбору команд в PowerShell для осуществления выше перечисленного на локальном компьютере. В разделе “управление службами удаленных компьютерах” мы рассмотрим, ограничения работы в PowerShell v2 и v3. Подробности под катом.

Предыдущая статья:Управляем службами Windows с помощью PowerShell. Часть 1. Получаем статус служб

PS C:\> get-service bits Status Name DisplayName ------ ---- ----------- Running bits Background Intelligent Transfer Ser... Так как команда для получения статуса службы называется Get-Service, догадаться о том, как пишутся другие команды не составит труда. На худой конец мы можем спросить у PowerShell обо всех командах, так или иначе относящихся к работе со службами. Обратите внимание, что мы использовали параметр –noun для получения всех команд, связанных со службами.

Взглянем на эти команды внимательнее.

STOP-SERVICE

Чтобы остановить службу, мы должны уточнить ее имя.PS C:\> stop-service wuauserv

Однако в конвейер ничего не будет передано. Некоторые командлеты, такие как Stop-Service, созданы таким образом, что по умолчанию они не записывают объект в конвейер. Мы же заставим это сделать, использовав параметр –Passthru.

PS C:\> stop-service bits -PassThru Status Name DisplayName ------ ---- ----------- Stopped bits Background Intelligent Transfer Ser...

Если служба не запущена, то командлет ничего не выведет, равно как и не выдаст никакой ошибки. Поэтому иногда лучше передать объект в Stop-Service (естественно использовав при этом параметр –whatif).

PS C:\> get-service browser | stop-service -WhatIf What if: Performing operation “Stop-Service” on Target “Computer Browser (browser)”.

Параметр –WhatIf был добавлен для того, чтобы мы посмотрели, что будет, если командлет будет запущен. Когда я удостоверюсь, что это именно та служба, которая меня интересует, я просто удалю -Whatif и остановлю службу.

PS C:\> get-service browser | stop-service

Как я уже упомянул выше, если служба уже остановлена, то командлет ничего не сделает. И использование Stop-Service в этом случае никому не навредит. Однако я все же предпочитают более цивилизованный подход, а именно:

PS C:\> get-service bits | where {$_.status -eq 'running'} | stop-service -pass Status Name DisplayName ------ ---- ----------- Stopped bits Background Intelligent Transfer Ser...

Если служба запущена, то объект передается в конвейер и отправляется в Stop-Service. Ниже приведен вариант с остановкой нескольких служб.

PS C:\> get-service bits,wsearch,winrm,spooler | where {$_.status -eq 'running'} | stop-service -whatif What if: Performing operation "Stop-Service" on Target "Print Spooler (spooler)". What if: Performing operation "Stop-Service" on Target "Windows Remote Management (WS-Management) (winrm)". What if: Performing operation "Stop-Service" on Target "Windows Search (wsearch)".

Некоторые службы не захотят останавливаться – в силу наличия зависимых служб – что мы и видим на скриншоте ниже.

В таком случае используем параметр –Force. В большинстве случаев это работает, но без “защиты от дурака”. Помните, что команда также остановит зависимые службы.

PS C:\> stop-service lanmanserver -force –PassThru Status Name DisplayName ------ ---- ----------- Stopped Browser Computer Browser Stopped lanmanserver Server

START-SERVICE

Запуск службы осуществляется аналогичным образом. Он поддерживает параметр –Whatif, и вам придется использовать –Passthru, чтобы увидеть объекты.

PS C:\> start-service wuauserv -PassThru Status Name DisplayName ------ ---- ----------- Running wuauserv Windows Update

И снова: если служба уже запущена, командлет ничего не сделает. Однако вы можете попытаться запустить службу и получите такую ошибку.

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

PS C:\> get-service lanmanserver | Foreach { start-service $_.name -passthru; start-service $_.DependentServices -passthru} Status Name DisplayName ------ ---- ----------- Running lanmanserver Server Running Browser Computer Browser

Мы должны явно получить зависимые службы, потому что Start-Service не запустит автоматически их.

RESTART-SERVICE

Вы удивитесь, но перезапуск службы работает также как два предыдущих примера. Используйте –Passthru, если хотите убедиться, что служба запущена.

PS C:\> restart-service spooler -PassThru Status Name DisplayName ------ ---- ----------- Running spooler Print Spooler

Так как мы осуществляем остановку службы, нам может понадобиться параметр –Force.

ПРИОСТАНОВКА И ВОЗОБНОВЛЕНИЕ РАБОТЫ

Работа некоторых служб может быть приостановлена на некоторое время, а затем возобновлена, и мы можем это сделать через PowerShell. Однако если служба не удовлетворяет требованиям, мы получим такие ошибки. (на примере показано, что мы пытались приостановить службу bits)

В чем же проблема? Смотрим на объект (используя Get-Service).

PS C:\> get-service bits | select * Name : bits RequiredServices : {RpcSs, EventSystem} CanPauseAndContinue : False CanShutdown : False CanStop : True DisplayName : Background Intelligent Transfer Service DependentServices : {} MachineName : . ServiceName : bits ServicesDependedOn : {RpcSs, EventSystem} ServiceHandle : SafeServiceHandle Status : Running ServiceType : Win32ShareProcess Site : Container :

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

PS C:\> get-service | where {$_.CanPauseandContinue} Status Name DisplayName ------ ---- ----------- Running LanmanServer Server Running LanmanWorkstation Workstation Running MSSQLSERVER SQL Server (MSSQLSERVER) Running O2FLASH O2FLASH Running stisvc Windows Image Acquisition (WIA) Running Winmgmt Windows Management Instrumentation

Как мы видим, не так много служб удовлетворяют этому требованию.

PS C:\> suspend-service o2flash -PassThru Status Name DisplayName ------ ---- ----------- Paused O2FLASH o2flash

Готовы возобновить работу службы? Используйте следующее выражение:

PS C:\> resume-service o2flash -PassThru Status Name DisplayName ------ ---- ----------- Running O2FLASH o2flash

Оба командлета также поддерживают –Whatif.

УДАЛЕННЫЕ СЛУЖБЫ

Как вы могли обратить внимание, все примере выше мы демонстрировали на локальном машине. И это неслучайно. К сожалению даже в PowerShell v3, ни у одного из этих командлетов нет параметра, который позволял бы управлять службой на удаленном компьютере. Get-Service, конечно, поддерживает параметр –Computername, но не более. Службу лицезреть вы сможете, а что-либо с ней сделать не получится. Нет, можно, конечно, если удаленный компьютер работает с PS v2 и включен PowerShell Remoting. Тогда мы можете использовать все выше приведенные команды, используя Invoke-Command для удаленного компьютера или PSSession. С другой стороны, проще управлять одной службой на нескольких серверах.

PS C:\> Invoke-Command {restart-service dns –passthru} –comp chi-dc03,chi-dc02,chi-dc01

Управление службами на удаленных компьютерах не ограничивается вышеперечисленным, но это уже будет предмет рассмотрения последующих статей. Все эти командлеты могут быть использованы в конвейерном выражении и зачастую это лучший вариант. Использование Get-Service для получения объектов и последующая передача их в подходящий командлет.

УСТАНАВЛИВАЕМ УДАЛЕННЫЙ СТАТУС

Итак, мы выяснили, что у командлета Stop-Service отсутствует такой полезный параметр как –Computername. Мы можете использовать эти команды в удаленной сессии, обратившись к командлету Invoke-Command, что уже само по себе продуктивно, если вы работаете со службой на нескольких компьютерах. Одно можно запускать, останавливать, перезапускать, ставить на паузу и запускать заново, используя Set-Service.

PS C:\> set-service wuauserv -ComputerName chi-dc03 -Status stopped -WhatIf What if: Performing operation "Set-Service" on Target "Windows Update (wuauserv)".

Эта команда поддерживает параметр –WhatIf. Вы также должны использовать –Passthru для передачи объектов в конвейер.

PS C:\> set-service bits -ComputerName chi-dc03 -Status running -PassThru Status Name DisplayName ------ ---- ----------- Running bits Background Intelligent Transfer Ser...

Валидными значениям для параметра –Status являются “запущена” (running), “остановлена” (stopped) и “на паузе” (paused). Помните, что у службы есть зависимые службы, мы не сможете изменять ее, что и продемонстрировано на скриншоте ниже.

К сожалению, у Set-Service отсутствует параметр –Force, поэтому придется вернуться к использованию PowerShell remoting и Invoke-Command. Если вы хотите перезапустить удаленную службу, используйте следующую команду:

PS C:\> set-service w32time -ComputerName chi-dc03 -Status Stopped -PassThru | set-service -PassThru -Status Running Status Name DisplayName ------ ---- ----------- Running w32time Windows Time

Не забудьте использовать –Passthru, в противном случае вторая команда Set-Service ничего не осуществит. Что по мне, так я предпочитаю работать сразу с несколькими службами, которые я не могу удаленно остановить, используя Set-Service, хотя их запуск проблем составляет. Я использую Invoke-Command. Но помните, что используя параметр –Computername PowerShell осуществляет подключение, используя RPC и DCOM, что может привести к проблемам с файрволом. Invoke-Command использует PowerShell remoting, который мы может быть еще не настроили или не включили.

УСТАНАВЛИВАЕМ ТИП АВТОЗАПУСКА СЛУЖБЫ

Set-Service полезнен, когда вы хотите включить или отключить службу, используя параметр –StartupType. Если Вы настроили службу, используя значения Automatic, Manual or Disabled. К сожалению, не существует варианта для Automatic (Delayed).

PS C:\> set-service remoteregistry -StartupType Manual -WhatIf What if: Performing operation "Set-Service" on Target "Remote Registry (remoteregistry)". PS C:\> set-service remoteregistry -StartupType Manual -PassThru Status Name DisplayName ------ ---- ----------- Stopped remoteregistry Remote Registry

Однако, просто взглянув на объект, мы не сможем сказать, к какому типу автозагрузки он относится.

PS C:\> get-service remoteregistry | select * Name : remoteregistry RequiredServices : {RPCSS} CanPauseAndContinue : False CanShutdown : False CanStop : False DisplayName : Remote Registry DependentServices : {} MachineName : . ServiceName : remoteregistry ServicesDependedOn : {RPCSS} ServiceHandle : SafeServiceHandle Status : Stopped ServiceType : Win32ShareProcess Site : Container :

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

PS C:\> set-service remoteregistry -StartupType Disabled -PassThru Status Name DisplayName ------ ---- ----------- Running remoteregistry Remote Registry

Так что если вы хотите выключить и остановить (или включить и запустить) службу, передайте объект в подходящий командлет.

PS C:\> set-service remoteregistry -StartupType Disabled -PassThru | Stop-Service -PassThru Status Name DisplayName ------ ---- ----------- Stopped remoteregistry Remote Registry

Технически, Set-Service позволяет вам изменить отображаемое имя службы и описание, но лично мне никогда не приходилось использовать в своей работе. Я использую Set-Service для включения и выключения служб. Если необходимо управлять службами удаленно, то я использую Invoke-Command. Все, что я продемонстрировал в последних статьях, было связано с использованием специфических типов объектов службы, которые, как вы могли заметить, имеют некоторые ограничения. В следующей статье мы рассмотрим другие возможности по управлению службами, которые призваны обойти эти ограничения.

Upd: В посте приведены переводы статей с портала 4sysops.comManaging Services the PowerShell way – Part 3Managing Services the PowerShell way – Part 4

habr.com

Профили в PowerShell

Что такое профиль в PowerShell ? По сути это обычный скрипт .ps1, выполняющийся при запуске оболочки PowerShell. Профиль можно использовать для настройки окружения — добавлять алиасы, задавать функции и переменные, импортировать модули, изменять внешний вид консоли и многое другое. Новые элементы, добавленные в профиль, будут доступны в каждом сеансе без необходимости импортировать или создавать их заново.

Всего в PowerShell поддерживаются четыре основных профиля:

Текущий пользователь, текущее приложение — $Home\Documents\WindowsPowerShell\profile.ps1;
Текущий пользователь, все приложения — $Home\Documents\profile.ps1;
Все пользователи, текущее приложение — $PsHome\MicrosoftPowerShell_profile.ps1;
Все пользователи, все приложения — $PsHome\profile.ps1.

В переменной $Home хранится путь к домашнему каталогу текущего пользователя (для Win 7 это C:\Users\user_name), а в $PsHome — к каталогу установки PowerShell (C:\Windows\System32\WindowsPowerShell\v1.0).

Текущее приложение — это приложение Microsoft.PowerShell, которое и предоставляет нам интерфейс командной строки. Плюс к этому другие приложения PowerShell тоже могут поддерживать собственные профили. Например PowerShell ISE использует профили:

$Home\My Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1 — для текущего пользователя;
$PsHome\Microsoft.PowerShellISE_profile.ps1 — для всех пользователей.

При наличии нескольких профилей предпочтение отдается более узконаправленному. Узнать, какой профиль используется на данный момент можно, введя команду $profile. Будет выведен полный путь к профилю, который интерпретатор команд пытается использовать в качестве основного. Также в свойствах переменной $Profile хранятся пути ко всем доступным профилям, узнать их можно командой:

$Profile | Get-Member -MemberType NoteProperty

Говоря о доступных профилях стоит учесть один момент, а именно — по умолчанию профили не созданы. Они существуют только если вы создали их. Узнать, был ли создан пользовательский профиль PowerShell можно командой:

Test-Path $profile

Если профиль существует, эта команда вернет True, в противном случае — False.

Для создания профиля можно использовать командлет New-Item. Например, создать профиль текущего пользователя в текущем приложении можно командой:

New-Item -ItemType file -Path $profile -force

Профиль создается пустым и его надо наполнить. Откроем его в блокноте командой notepad $profile и посмотрим, как можно изменить некоторые настройки PowerShell:

# Изменение внешнего вида консоли (Get-Host).UI.RawUI.ForegroundColor = ″green″ (Get-Host).UI.RawUI.BackgroundColor = ″black″ (Get-Host).UI.RawUI.CursorSize = 10 (Get-Host).UI.RawUI.WindowTitle = ″My Window″ # Установка директорию по умолчанию Set-Location C:\ # Новый алиас для Get-Help Set-Alias HelpMе Get-Help # Добавление всех зарегистрированных оснасток и модулей Get-Pssnapin -Registered | Add-Pssnapin -Passthru -ErrorAction SilentlyContinue Get-Module -ListAvailable| Import-Module -PassThru -ErrorAction SilentlyContinue # Очиcтка экрана Clear-Host # Приветствие себя любимого Write-Host ″Hello, my friend !!!″

Записываем все это в профиль, перезапускаем консоль и смотрим, что получилось. И тут надо помнить об еще одном важном моменте — политике выполнения скриптов. Как я уже говорил, профиль представляет из себя обычный скрипт, а значение политики по умолчанию — Restricted, что запрещает выполнение любых скриптов в PowerShell. Поэтому для того, чтобы профиль применился нужно изменить текущее значение политики :

Set-ExecutionPolicy Remotesigned

После изменения политики еще раз перезапускаем консоль, профиль применяется и вот результат.

Грамотно созданный профиль может облегчить работу с PowerShell, однако стоит соблюдать меру. Большой профиль, загружающий множество оснасток, может привести к снижению скорости запуска приложений. Кстати, может возникнуть ситуация, когда необходимо запустить оснастку PowerShell без использования профилей. Для этого используется параметр -NoProfile программы PowerShell.exe. Сделать это можно, введя в окне Run команду:

PowerShell -noprofile

И несколько слов об удаленных сеансах. При удаленном подключении профили не запускаются автоматически, и переменная $Profile в удаленных сеансах не определена. Однако в каждом удаленном сеансе используется конфигурация сеанса, которую можно использовать для создания специальной среды для удаленных пользователей.

В качестве примера зарегистрируем на локальном компьютере конфигурацию сеанса WithProfile, где с помощью параметра -StartupScript укажем PowerShell применять заданный скрипт в любом сеансе, для которого используется эта конфигурация:

Теперь если при подключении к этому компьютеру указать имя конфигурации WithProfile, то к сеансу применится текущий профиль:

New-PsSession -ComputerName SRV1 -ConfigurationName WithProfile

Ну вот вроде и все, что я хотел рассказать о пользовательских профилях в PowerShell.

windowsnotes.ru

Управление виртуальными машинами Windows с помощью PowerShell Direct

05/02/2016
Время чтения: 6 мин
Соавторы

С помощью PowerShell Direct можно запускать произвольный код PowerShell на виртуальной машине с Windows10 или Windows Server2016 с узла Hyper-V независимо от конфигурации сети и параметров удаленного управления.

Запустить PowerShell Direct можно разными способами:

Интерактивный сеанс: щелкните здесь, чтобы создать и завершить интерактивный сеанс PowerShell с помощью Enter-PSSession.
Разовый сеанс для выполнения одной команды или одного сценария: щелкните здесь, чтобы выполнить сценарий или команду с помощью Invoke-Command.
Постоянный сеанс (сборка 14280 и более поздние): щелкните здесь для создания постоянного сеанса с помощью New-PSSession.Продолжите работу, скопировав файл на виртуальную машину и с нее с помощью Copy-Item, а затем отключитесь с помощью Remove-PSSession.

Требования

Требования к операционной системе:

Узел: Windows10, Windows Server2016 или более поздней версии с Hyper-V.
Гость/виртуальная машина: Windows10, Windows Server2016 или более поздней версии.

Если вы управляете виртуальными машинами более ранних версий, используйте средство "Подключение к виртуальной машине" (VMConnect) или настройте для этой машины виртуальную сеть.

Требования к конфигурации:

Виртуальная машина должна работать на узле локально.
Виртуальная машина должна быть включена и иметь хотя бы один настроенный профиль пользователя.
Необходимо войти в учетную запись администратора Hyper-V на хост-компьютере.
Необходимо указать действительные учетные данные пользователя для виртуальной машины.

Создание и завершение интерактивного сеанса PowerShell

Для выполнения команд PowerShell на виртуальной машине проще всего запустить интерактивный сеанс.

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

Запуск интерактивного сеанса:

На узле Hyper-V откройте PowerShell от имени администратора.
Выполните одну из указанных ниже команд, чтобы создать интерактивный сеанс, используя имя или GUID виртуальной машины:
Enter-PSSession -VMName <VMName> Enter-PSSession -VMId <VMId>
Укажите учетные данные для виртуальной машины при отображении соответствующего запроса.
Выполните команды на виртуальной машине.

Для вашей командной строки PowerShell должен отображаться префикс VMName, как показано ниже:
[VMName]: PS C:\>
Любая выполненная команда выполняется на виртуальной машине. Для проверки можно выполнить ipconfig или hostname, чтобы убедиться, что эти команды выполняются на виртуальной машине.
После завершения работы выполните следующую команду, чтобы закрыть сеанс:
Exit-PSSession

Примечание. Если сеанс не подключается, см. раздел Диагностика для определения возможных причин.

Дополнительные сведения об этих командлетах см. в разделах Enter-PSSession и Exit-PSSession.

Запуск сценария или команды с помощью командлета Invoke-Command

PowerShell Direct с Invoke-Command идеально подходит для ситуаций, когда нужно выполнить одну команду или один сценарий на виртуальной машине, после чего можно прекратить взаимодействие с виртуальной машиной.

Запуск одной команды:

На узле Hyper-V откройте PowerShell от имени администратора.
Выполните одну из указанных ниже команд, чтобы создать сеанс, используя имя или GUID виртуальной машины:
Invoke-Command -VMName <VMName> -ScriptBlock { command } Invoke-Command -VMId <VMId> -ScriptBlock { command }
Укажите учетные данные для виртуальной машины при отображении соответствующего запроса.

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

Запуск сценария:

На узле Hyper-V откройте PowerShell от имени администратора.
Выполните одну из указанных ниже команд, чтобы создать сеанс, используя имя или GUID виртуальной машины:
Invoke-Command -VMName <VMName> -FilePath C:\host\script_path\script.ps1 Invoke-Command -VMId <VMId> -FilePath C:\host\script_path\script.ps1
Укажите учетные данные для виртуальной машины при отображении соответствующего запроса.

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

Дополнительные сведения об этом командлете см. в статье Invoke-Command.

Копирование файлов с помощью New-PSSession и Copy-Item

Примечание. В сборках Windows 14280 и более поздних версий PowerShell Direct поддерживает только постоянные сеансы.

Постоянные сеансы PowerShell чрезвычайно полезны при написании сценариев, координирующих действия для одного или нескольких удаленных компьютеров. После создания постоянные сеансы выполняются в фоновом режиме, пока вы не решите удалить их. Это означает, что можно снова и снова ссылаться на один и тот же сеанс с помощью Invoke-Command или Enter-PSSession без передачи учетных данных.

По той же причине сеансы сохраняют состояние. Так как постоянные сеансы сохраняются, все созданные или переданные в них переменные сохраняются между вызовами. Существует несколько средств для работы с постоянными сеансами. В этом примере мы будем использовать New-PSSession и Copy-Item для перемещения данных с узла в виртуальную машину и из виртуальной машины на узел.

Создание сеанса с последующим копированием файлов:

На узле Hyper-V откройте PowerShell от имени администратора.
Выполните одну из указанных ниже команд, чтобы создать постоянный сеанс PowerShell для виртуальной машины с помощью New-PSSession.
$s = New-PSSession -VMName <VMName> -Credential (Get-Credential) $s = New-PSSession -VMId <VMId> -Credential (Get-Credential)
Укажите учетные данные для виртуальной машины при отображении соответствующего запроса.

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

Чтобы скопировать C:\host_path\data.txt на виртуальную машину с хост-компьютера, выполните следующую команду:
Copy-Item -ToSession $s -Path C:\host_path\data.txt -Destination C:\guest_path\
Скопируйте файл с виртуальной машины (на узел).

Чтобы скопировать C:\guest_path\data.txt на узел с виртуальной машины, выполните следующую команду:
Copy-Item -FromSession $s -Path C:\guest_path\data.txt -Destination C:\host_path\
Остановите постоянный сеанс с помощью Remove-PSSession.
Remove-PSSession $s

Диагностика

В PowerShell Direct выводится небольшой набор сообщений о распространенных ошибках. Ниже приведены наиболее распространенные ошибки, возможные причины и средства диагностики.

Параметры -VMName или -VMID не существуют

Проблема.Enter-PSSession, Invoke-Command или New-PSSession не имеют параметр -VMName или -VMId.

Возможные причины:Скорее всего, проблема состоит в том, что PowerShell Direct не поддерживается операционной системой сервера виртуальных машин.

Проверить сборку Windows можно с помощью следующей команды:

[System.Environment]::OSVersion.Version

Если применяется поддерживаемая сборка, возможно, ваша версия PowerShell не использует PowerShell Direct. Для PowerShell Direct и JEA требуется основной номер версии5 или выше.

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

$PSVersionTable.PSVersion

Ошибка: "Возможно, удаленный сеанс был завершен"

Примечание.Для Enter-PSSession в сборках узла с 10240 по 12400 все описанные ниже ошибки регистрируются как "Возможно, удаленный сеанс был завершен".

Сообщение об ошибке:

Enter-PSSession : An error has occurred which Windows PowerShell cannot handle. A remote session might have ended.

Возможные причины:

Виртуальная машина существует, но не выполняется.
Гостевая ОС не поддерживает PowerShell Direct (см. требования).
Оболочка PowerShell еще не доступна на гостевой виртуальной машине.
- Загрузка операционной системы не завершена.
- Правильная загрузка операционной системы невозможна.
- Во время загрузки требуется ввод данных пользователем.

Можно использовать командлет Get-VM, чтобы узнать, какие виртуальные машины выполняются на узле.

Сообщение об ошибке:

New-PSSession : An error has occurred which Windows PowerShell cannot handle. A remote session might have ended.

Возможные причины:

Одна из указанных выше причин— они все в равной мере применимы для New-PSSession
Ошибка в текущих сборках, когда требуется явная передача учетных данных с помощью -Credential. Когда это происходит, в операционной системе на виртуальной машине зависает вся служба и ее требуется перезапустить. Доступность сеанса можно проверить с помощью Enter-PSSession.

Чтобы обойти эту проблему с учетными данными, войдите на виртуальную машину с помощью VMConnect, откройте PowerShell и перезапустите службу vmicvmsession, используя следующую команду PowerShell:

Restart-Service -Name vmicvmsession

Ошибка: набор параметров не может быть разрешен

Сообщение об ошибке:

Enter-PSSession : Parameter set cannot be resolved using the specified named parameters.

Возможные причины:

-RunAsAdministrator не поддерживается при подключении к виртуальным машинам.

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

Можно передать учетные данные администратора на виртуальную машину с помощью параметра -Credential либо вручную при поступлении запроса.

Ошибка. Недопустимые учетные данные.

Сообщение об ошибке:

Enter-PSSession : The credential is invalid.

Возможные причины:

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

Ошибка. Входной параметр VMName не разрешается ни в одну виртуальную машину.

Сообщение об ошибке:

Enter-PSSession : The input VMName parameter does not resolve to any virtual machine.

Возможные причины:

Вы не являетесь администратором Hyper-V.
Виртуальная машина не существует.

С помощью командлета Get-VM можно проверить, имеется ли у используемых учетных данных роль администратора Hyper-V, а также просмотреть, какие виртуальные машины запущены локально и загружены.

Примеры и руководства пользователя

PowerShell Direct поддерживает JEA (Just Enough Administration). Чтобы оценить эту функцию, воспользуйтесь этим руководством пользователя.

См. примеры на веб-сайте GitHub.

docs.microsoft.com

Как запустить PowerShell script при запуске компьютера? Windows powershell открывается автоматически

powershell - Как запустить PowerShell script при запуске компьютера?

Запуск PowerShell скриптов по расписанию

Способ 1

Способ 2

Execution Policy

Запуск командлетов AppFabric

Открытие модуля AppFabric для Windows PowerShell

Импорт модуля AppFabric для Windows PowerShell

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

Управляем службами Windows с помощью PowerShell. Часть 2 / Блог компании Netwrix / Хабрахабр

STOP-SERVICE

START-SERVICE

RESTART-SERVICE

ПРИОСТАНОВКА И ВОЗОБНОВЛЕНИЕ РАБОТЫ

УДАЛЕННЫЕ СЛУЖБЫ

УСТАНАВЛИВАЕМ УДАЛЕННЫЙ СТАТУС

УСТАНАВЛИВАЕМ ТИП АВТОЗАПУСКА СЛУЖБЫ

Профили в PowerShell

Управление виртуальными машинами Windows с помощью PowerShell Direct

In this article

Требования

Создание и завершение интерактивного сеанса PowerShell

Запуск сценария или команды с помощью командлета Invoke-Command

Копирование файлов с помощью New-PSSession и Copy-Item

Диагностика

Параметры -VMName или -VMID не существуют

Ошибка: "Возможно, удаленный сеанс был завершен"

Ошибка: набор параметров не может быть разрешен

Ошибка. Недопустимые учетные данные.

Ошибка. Входной параметр VMName не разрешается ни в одну виртуальную машину.

Примеры и руководства пользователя