Включение подключения к удаленному рабочему столу для роли в облачных службах Azure с помощью PowerShellEnable Remote Desktop Connection for a Role in Azure Cloud Services using PowerShell. Powershell подключиться к другому компьютеру

PowerShell. О отложенных сессиях (about_Remote_Disconnected_Session) — Клёвый код

Начиная с Windows PowerShell 3.0, вы можете отключится от PSSession и подключиться к той же PSSession позднее с того же или с другого компьютера. Во время отключения от сеанса сессии поддерживается и команды в PSSession продолжают работать .

Функции отложенных сессий доступны, только если на компьютере к которому подключаются удаленно установлен Windows PowerShell 3.0 или более поздняя версия.

Функции отложенных сессий позволяют закрыть сеанс, в котором была создана PSSession, или закрыть консоль Windows PowerShell, или даже выключить компьютер, не нарушив работу команд запущенных в PSSession. Это особенно полезно для выполнения команд выполнение которых занимает продолжительное время. Это увеличивает запас времени на выполнение команд и предоставляет гибкий механизм для нужд ИТ-специалистов.

ПРИМЕЧАНИЕ: Нельзя отключаться от интерактивной сессии, которая началась с помощью командлета Enter-PSSession.

Вы можете использовать отложенные сессии при настройке удалённого компьютера через PSSession. При этом в результате разрыва соединения или отключения не произойдёт разрыв сесси.

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

Командлеты отложенных сессий

Следующие командлеты поддерживают функции отложенных сессий:Disconnect-PSSession: Отключает от PSSession.Connect-PSSession: Подключается к отложенной PSSession.Receive-PSSession: Возвращает результаты команд, которые выполнялись во время отключения от сесси.Get-PSSession: Возвращает PSSession, на локальном компьютере или на удаленных компьютерах.Invoke-Command: С использованием параметр InDisconnectedSession этот командлет создает PSSession и сразу отключается от неё.

Как работает функция отложенных сессий

Начиная с Windows PowerShell 3.0 сессии PSSession не зависят от сеансов в которых они создаются. Активная PSSession поддерживается на удаленном компьютере или на стороне сервера, даже если сеанс в котором была создана PSSession закрыт, и даже если компьютер был выключен или отключен от сети.

В Windows PowerShell 2.0, PSSession закрывалась на удаленном компьютере, когда сеанс в котором она была создана отключается от PSSession.

При отключении от PSSession, PSSession остается активной и поддерживается на удаленном компьютере. Сессия изменяет состояние из Running в Disconnected. К сессии в состоянии Disconnect можно подключиться из текущего сеанса или с другого сеанса на том же компьютере, или с другого компьютера. Удаленный компьютер, который будет поддерживать сессию должен быть запущен и подключен к сети.

Команды в отключенной PSSession продолжают работать на удаленном компьютере, пока команды не завершатся или пока буфер вывода не переполнится. Чтобы предотвратить приостановку выполнения команд при заполнении буфера вывода необходимо использовать параметр OutputBufferingMode в командлетах Disconnect-PSSession, New-PSSessionOption, или New-PSTransportOption.

Отложенные сессии поддерживаются в отключенном состоянии на удаленном компьютере. Они доступны для восстановления, пока не удалить PSSession, например, с помощью командлета Remove-PSSession, или пока в PSSession не истечёт время ожидания после отключения. Можно настроить время ожидания в PSSession с помощью параметров IdleTimeoutSec или IdleTimeout в командлетах Disconnect-PSSession, New-PSSessionOption, или New-PSTransportOption.

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

Как получить объект PSSession.

Начиная с Windows PowerShell 3.0, Get-PSSession командлет может получить объекты PSSession, как с локального компьютера так, и с удаленных компьютеров. Командлет может получить объекты сессий PSSession, созданных в текущем сеансе.

Чтобы получить объекты сессий PSSession на локальном компьютере или удаленных компьютерах, используйте параметры ComputerName или ConnectionURI. Без параметров Get-PSSession получает объекты PSSession, созданные в локальном сеансе независимо от того, к какому серверу они подсоединены.

Так же, что бы получить объект PSSession, можно указать компьютер на котором она работает, то есть сервер.

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

Следующая последовательность команд показывает, как работает командлет Get-PSSession.

Первая команда создает сессию с компьютером Server01. Сессия находится на компьютере Server01.

PS C:\ps-test> New-PSSession -ComputerName Server01 Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 Server01 Opened Microsoft.PowerShell Available

PS C:\ps-test> New-PSSession -ComputerName Server01

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

2 Session2 Server01 Opened Microsoft.PowerShell Available

Чтобы получить сессию, надо использовать параметр ComputerName в командлете Get-PSSession со значением Server01.

PS C:\ps-test> Get-PSSession -ComputerName Server01 Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 Server01 Opened Microsoft.PowerShell Available

PS C:\ps-test> Get-PSSession -ComputerName Server01

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

2 Session2 Server01 Opened Microsoft.PowerShell Available

Если значение параметра ComputerName в Get-PSSession указывает на локальный компьютер, Get-PSSession получает объекты PSSession которые работают и поддерживаются на локальном компьютере. И не получит сессии PSSession с компьютером Server01, даже если они были запущенны с локального компьютера.

PS C:\ps-test> Get-PSSession -ComputerName localhost PS C:\ps-test>

PS C:\ps-test> Get-PSSession -ComputerName localhost

PS C:\ps-test>

Чтобы получить сессии, которые были созданы в текущем сеансе, надо использовать командлет Get-PSSession без параметров. Эта команда получит сессии PSSession, которые был создан в текущем сеансе, в том числе и подключенную к компьютеру Server01.

PS C:\ps-test> Get-PSSession Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 Server01 Opened Microsoft.PowerShell Available

PS C:\ps-test> Get-PSSession

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

2 Session2 Server01 Opened Microsoft.PowerShell Available

Как отключиться от сессии

Чтобы отключиться от PSSession надо воспользоваться командлетом Disconnect-PSSession. Чтобы указать конкретную PSSession используется параметр Session или можно передать объекты PSSession по конвейеру из командлетов New-PSSession, Get-PSSession, или Disconnect-PSSession.

Следующая команда отключает PSSession с компьютером Server01. Обратите внимание, что свойство State имеет свойство Disconnected, а свойство Availability имеет статус None.

PS C:\> Get-PSSession -ComputerName Server01 | Disconnect-PSSession Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 Server01 Disconnected Microsoft.PowerShell None

PS C:\> Get-PSSession -ComputerName Server01 | Disconnect-PSSession

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

2 Session2 Server01 Disconnected Microsoft.PowerShell None

Для создания сессии в состоянии Disconnected, можно воспользоваться параметром InDisconnectedSession в командлете Invoke-Command. Командлет при этом создаст сеанс, начнёт выполнять команду, и сразу отключиться, до того, как команда вернёт какой либо ответ.

Следующая команда выполняет команду Get-WinEvent в сессии с состоянием Disconnected на удаленном компьютере Server02.

PS C:\> Invoke-Command -ComputerName Server02 -InDisconnectedSession ` -ScriptBlock {Get-WinEvent -LogName "Windows PowerShell"} Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 4 Session3 Server02 Disconnected Microsoft.PowerShell None

PS C:\> Invoke-Command -ComputerName Server02 -InDisconnectedSession `

-ScriptBlock {Get-WinEvent -LogName "Windows PowerShell"}

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

4 Session3 Server02 Disconnected Microsoft.PowerShell None

Как подключиться к отложенной сессии

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

Можно создать PSSession, выполнить команды в PSSession, отключиться от PSSession, закрыть Windows PowerShell, и выключить компьютер. Через несколько часов, можно войти в другой компьютер, получить PSSession, подключиться к ней, и получить результаты команд, которые выводились в PSSession в то время как она находилась в состоянии Disconnected. Затем можно запустить несколько команд в этой же сессии.

Для подключения к PSSession в состоянии Disconnected используется командлет Connect-PSSession. Для указания PSSession можно воспользоваться параметрами ComputerName или ConnectionURI, или передать объекты PSSession по конвейеру из командлета Get-PSSession.

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

PS C:\> Get-PSSession -ComputerName Server02 Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 juneb-srv8320 Disconnected Microsoft.PowerShell None 4 Session3 juneb-srv8320 Disconnected Microsoft.PowerShell None

PS C:\> Get-PSSession -ComputerName Server02

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

2 Session2 juneb-srv8320 Disconnected Microsoft.PowerShell None

4 Session3 juneb-srv8320 Disconnected Microsoft.PowerShell None

Следующая команда подключается к Session2. PSSession теперь открыта и доступна.

PS C:> Connect-PSSession -ComputerName Server02 -Name Session2 Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 juneb-srv8320 Opened Microsoft.PowerShell Available

PS C:> Connect-PSSession -ComputerName Server02 -Name Session2

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

2 Session2 juneb-srv8320 Opened Microsoft.PowerShell Available

Как получить результаты

Чтобы получить результаты команд, которые выводились во время того, как PSSession находилась в состоянии Disconnected, необходимо воспользоваться командлетом Receive-PSSession.

Можно использовать Receive-PSSession в дополнение или вместо командлета Connect-PSSession. Если сессия уже переподсоединилась и находиться в состоянии Opened, Receive-PSSession получает результаты команд, которые выводились, когда сеанс был в состоянии Disconnected. Если PSSession по-прежнему находится в состоянии Disconnected, Receive-PSSession подключается к нему, и получает результаты команд, которые выводились во время дисконнекта.

Receive-PSSession может возвращать результаты команд в виде объекта задания (асинхронно) или непосредственно с хоста на котором выполняется сессия (синхронно). Используя параметр OutTarget можно выбрать job или host. По умолчанию выбирается значение host. Если команда началась в текущем сеансе в качестве job, оно возвращается как job по умолчанию.

Следующая команда использует командлет Receive-PSSession, для подключения к PSSession на компьютере Server02 и получения результатов командлета Get-WinEvent, который выполняется в сессии Session3. Команда использует параметр OutTarget, чтобы получить результаты в виде job.

PS C:\> Receive-PSSession -ComputerName Server02 -Name Session3 -OutTarget Job Id Name PSJobTypeName State HasMoreData Location -- ---- ------------- ----- ----------- -------- 3 Job3 RemoteJob Running True Server02

PS C:\> Receive-PSSession -ComputerName Server02 -Name Session3 -OutTarget Job

Id Name PSJobTypeName State HasMoreData Location

-- ---- ------------- ----- ----------- --------

3 Job3 RemoteJob Running True Server02

Чтобы получить результаты задания, можно воспользоваться командлетом Receive-Job.

PS C:\ps-test> Get-Job | Receive-Job -Keep ProviderName: PowerShell TimeCreated Id LevelDisplayName Message PSComputerName ----------- -- ---------------- ------- -------------- 5/14/2012 7:26:04 PM 400 Information Engine stat Server02 5/14/2012 7:26:03 PM 600 Information Provider "W Server02 5/14/2012 7:26:03 PM 600 Information Provider "C Server02 5/14/2012 7:26:03 PM 600 Information Provider "V Server02

PS C:\ps-test> Get-Job | Receive-Job -Keep

ProviderName: PowerShell

TimeCreated Id LevelDisplayName Message PSComputerName

----------- -- ---------------- ------- --------------

5/14/2012 7:26:04 PM 400 Information Engine stat Server02

5/14/2012 7:26:03 PM 600 Information Provider "W Server02

5/14/2012 7:26:03 PM 600 Information Provider "C Server02

5/14/2012 7:26:03 PM 600 Information Provider "V Server02

Состояние и доступность

Свойства состояния и доступности в отключенной PSSession показывают доступна ли сессия для подключения к ней.

Когда PSSession подключена к текущему сеансу, её состояние Opened и доступность Available. При отключении от PSSession, состояние PSSession Disconnected, и его доступность имеет значение None.

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

Чтобы определить, можно ли подключиться к PSSession, используется свойство доступности (Availability). Состояние свойства Availability — None означает, что вы можете подключиться к сессии. Значение Busy означает, что вы не можете подключиться к PSSession, потому что она связана с другим сеансом.

В следующем примере запущено две сессии (в разных консолях Windows PowerShell) на одном компьютере. Значение Статуса и доступности в каждом сеансе изменяют значения в зависимости от того подключена сессия или нет.

#Session 1: PS C:\> New-PSSession -ComputerName Server30 -Name Test Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Test Server30 Opened Microsoft.PowerShell Available #Session 2: PS C:\> Get-PSSession -ComputerName Server30 -Name Test Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Test Server30 Disconnected Microsoft.PowerShell Busy #Session 1 PS C:\> Get-PSSession -ComputerName Server30 -Name Test | Disconnect-PSSession Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Test Server30 Disconnected Microsoft.PowerShell None #Session 2 PS C:\> Get-PSSession -ComputerName Server30 Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Test Server30 Disconnected Microsoft.PowerShell None #Session 2 PS C:\> Connect-PSSession -ComputerName Server01 -Name Test Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 3 Test Server30 Opened Microsoft.PowerShell Available #Session 1 PS C:\> Get-PSSession -ComputerName Server30 Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Test Server30 Disconnected Microsoft.PowerShell Busy

#Session 1:

PS C:\> New-PSSession -ComputerName Server30 -Name Test

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

1 Test Server30 Opened Microsoft.PowerShell Available

#Session 2:

PS C:\> Get-PSSession -ComputerName Server30 -Name Test

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

1 Test Server30 Disconnected Microsoft.PowerShell Busy

#Session 1

PS C:\> Get-PSSession -ComputerName Server30 -Name Test | Disconnect-PSSession

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

1 Test Server30 Disconnected Microsoft.PowerShell None

#Session 2

PS C:\> Get-PSSession -ComputerName Server30

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

1 Test Server30 Disconnected Microsoft.PowerShell None

#Session 2

PS C:\> Connect-PSSession -ComputerName Server01 -Name Test

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

3 Test Server30 Opened Microsoft.PowerShell Available

#Session 1

PS C:\> Get-PSSession -ComputerName Server30

Id Name ComputerName State ConfigurationName Availability

-- ---- ------------ ----- ----------------- ------------

1 Test Server30 Disconnected Microsoft.PowerShell Busy

Время простоя

Отложенные сессии поддерживаются на удаленном компьютере, пока вы их не удалите, например, с помощью командлета Remove-PSSession, или после истечения времени простоя. Свойство IdleTimeout в PSSession определяет, как долго отложенная сессия будет простаивать, прежде чем она будет удалена.

Сессии PSSession простаивают, когда «heartbeat thread» не получает никакого ответа. При отключении от сессии создаётся простой и начинает отсчитываться время, даже если команды по-прежнему работают в отложенной сессии. Windows PowerShell считает отложенные сессии активными, но в состоянии простоя.

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

Свойство конфигурации сессий IdleTimeoutMs определяет время простоя по умолчанию, которое используются при конфигурации сессий. Можно переопределить значение по умолчанию, но значение, которое задаётся не может превышать значение свойства MaxIdleTimeoutMs конфигурации сеанса.

Чтобы узнать значение свойств конфигурации сеанса IdleTimeoutMs и MaxIdleTimeoutMs, используется следующий формат команд.

Get-PSSessionConfiguration | Format-Table Name, IdleTimeoutMs, MaxIdleTimeoutMs

Значение по умолчанию в конфигурации сеанса можно переопределить и установить тайм-аут простоя из PSSession при создании PSSession и когда вы отключаетесь.

Если вы являетесь членом группы администраторов на удаленном компьютере, вы также можете создавать и менять значение свойства конфигурации сессии IdleTimeoutMs и MaxIdleTimeoutMs.

ЗАМЕТКИ:

Значение времени простоя конфигураций сеансов и опций сеансов в миллисекундах. Значение времени простоя сессий и параметры конфигурации сессий в секундах.

Можно установить время простоя из PSSession при создании PSSession (New-PSSession, Invoke-Command), и когда происходит отключение от сессии(Disconnect-PSSession). Тем не менее, нельзя изменить значение IdleTimeout при подключении к PSSession (Connect-PSSession) или при получении результатов из сессии (Receive-PSSession).

Командлеты Connect-PSSession и Receive-PSSession имеют параметр SessionOption, который принимает объекты SessionOption. Их возвращает командлет New-PSSessionOption. Тем не менее, значение IdleTimeout в объекте SessionOption и значение IdleTimeout в переменных $PSSessionOption не изменяют значение свойства IdleTimeout в PSSession при выполнении команд Connect-PSSession или Receive-PSSession.

Чтобы создать сеанс PSSession с определенным значением времени простоя, надо изменить привилегированную переменную $PSSessionOption, и установить значение свойства IdleTimeout до нужного значения (в миллисекундах).

При создании сеанса PSSession, значения в привилегированной переменной $PSSessionOption имеют приоритет над значениями в конфигурации сеанса.

Например, эта команда устанавливает время простоя 48 часов.

PS C:\> $PSSessionOption = New-PSSessionOption -IdleTimeoutMSec 172800000

Чтобы создать сеанс PSSession с определенным значением времени простоя, используется параметр IdleTimeoutMSec командлета New-PSSessionOption. Затем значение переменной передаётся в параметр SessionOption, в командлет New-PSSession или Invoke-Command.

Значения устанавливающиеся при создании сеанса имеют приоритет над значениями, заданными в привилегированной переменной $PSSessionOption и конфигурации сеанса.Например:

PS C:\> $o = New-PSSessionOption -IdleTimeoutMSec 172800000 PS C:\> New-PSSession -SessionOption $o

PS C:\> $o = New-PSSessionOption -IdleTimeoutMSec 172800000

PS C:\> New-PSSession -SessionOption $o

Чтобы изменить время простоя из PSSession при отключении, используется параметр IdleTimeoutSec в командлете Disconnect-PSSession.

Например:

PS C:\> Disconnect-PSSession -IdleTimeoutSec 172800

Чтобы создать конфигурацию сеанса с заданным или максимальным временем простоя, используются параметры IdleTimeoutSec или MaxIdleTimeoutSec командлета New-PSTransportOption. Затем надо воспользоваться параметром передачи значении TransportOption командлета Register-PSSessionConfiguration.

Например:

PS C:\> $o = New-PSTransportOption -IdleTimeoutSec 172800 -MaxIdleTimeoutSec 259200 PS C:\> Register-PSSessionConfiguration -Name Test -TransportOption $o

PS C:\> $o = New-PSTransportOption -IdleTimeoutSec 172800 -MaxIdleTimeoutSec 259200

PS C:\> Register-PSSessionConfiguration -Name Test -TransportOption $o

Чтобы изменить время простоя по умолчанию или максимальное время простоя в конфигурации сессии, используйется параметры IdleTimeoutSec и MaxIdleTimeoutSec командлета New-PSTransportOption. Затем опция TransportOption командлета Set-PSSessionConfiguration.Например:

PS C:\> $o = New-PSTransportOption -IdleTimeoutSec 172800 -MaxIdleTimeoutSec 259200 PS C:\> Set-PSSessionConfiguration -Name Test -TransportOption $o

PS C:\> $o = New-PSTransportOption -IdleTimeoutSec 172800 -MaxIdleTimeoutSec 259200

PS C:\> Set-PSSessionConfiguration -Name Test -TransportOption $o

Режим работы буфера вывода

Режим работы буфера вывода в PSSession определяет поведение PSSession при заполнении буфера вывода.

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

Допустимые значения:

Block: При заполнении буфера вывода, выполнение команд приостанавливается до тех пор, пока буфер не освободится.Drop: Когда буфер вывода полон, выполнение продолжается. При этом старая информация удаляется, а новая записывается.

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

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

Свойство OutputBufferingMode конфигурации сессии изменяет значение по умолчанию режима работы буферизации вывода, которое используется для конфигурации сессии.

Чтобы посмотреть значение OutputBufferingMode конфигурации сеанса, используется следующий формат команды.

(Get-PSSessionConfiguration <ConfigurationName>).OutputBufferingMode

или

Get-PSSessionConfiguration | Format-Table Name, OutputBufferingMode

Можно переопределить значение по умолчанию в конфигурации сессии или установить режим работы буфера вывода PSSession при создании, отключении и подключении к PSSession.

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

Чтобы создать сессию PSSession с режимом работы буфера вывода в состоянии Drop, можно изменить привилегированную переменную $PSSessionOption, в которой установить свойство OutputBufferingMode в значении Drop.

При создании сессии PSSession, значения в переменной $PSSessionOption имеют приоритет над значениями в конфигурации сеанса.

Например:

PS C:\> $PSSessionOption = New-PSSessionOption -OutputBufferingMode Drop

Чтобы создать сессию PSSession в режиме работы буфера вывода в состоянии Drop, можно использовать параметр OutputBufferingMode со значением Drop командлета New-PSSessionOption. Затем передать значения в параметр SessionOption командлетов New-PSSession или Invoke-Command.

Значения установленные при создании сессии имеют приоритет над значениями, заданными в привилегированной переменной $PSSessionOption и конфигурации сеанса.

Например:

PS C:\> $o = New-PSSessionOption -OutputBufferingMode Drop PS C:\> Connect-PSSession -Cn Server01 -Name Test -SessionOption $o

PS C:\> $o = New-PSSessionOption -OutputBufferingMode Drop

PS C:\> Connect-PSSession -Cn Server01 -Name Test -SessionOption $o

Чтобы изменить режим работы буфера вывода в PSSession при отключении, можно использовать параметр OutputBufferingMode командлета Disconnect-PSSession.Например:

PS C:\> Disconnect-PSSession -OutputBufferingMode Drop

Чтобы изменить режим работы буфера вывода в PSSession при повторном подключении, можно использовать параметр OutputBufferingMode командлета New-PSSessionOption для создания параметра сессии со значением Drop. Затем, передать полученные значение в параметр SessionOption командлетов Connect-PSSession или Receive-PSSession.

Например:

PS C:\> $o = New-PSSessionOption -OutputBufferingMode Drop PS C:\> Connect-PSSession -Cn Server01 -Name Test -SessionOption $o

PS C:\> $o = New-PSSessionOption -OutputBufferingMode Drop

PS C:\> Connect-PSSession -Cn Server01 -Name Test -SessionOption $o

Чтобы создать конфигурацию сеанса с режимом работы буфера вывода по умолчанию в состоянии Drop, используйте параметр OutputBufferingMode в командлете New-PSTransportOption для создания объекта с опцией транспорта в значении Drop. Затем передайте значение в параметр TransportOption командлета Register-PSSessionConfiguration.

Например:

PS C:\> $o = New-PSTransportOption -OutputBufferingMode Drop PS C:\> Register-PSSessionConfiguration -Name Test -TransportOption $o

PS C:\> $o = New-PSTransportOption -OutputBufferingMode Drop

PS C:\> Register-PSSessionConfiguration -Name Test -TransportOption $o

Чтобы изменить режим работы буфера вывода в конфигурации сессии по умолчанию, используется параметр OutputBufferingMode в командлете New-PSTransportOption для создания транспорта со значением Drop. Затем необходимо передать значение в опцию SessionOption в командлете Set-PSSessionConfiguration.

Например:

PS C:\> $o = New-PSTransportOption -OutputBufferingMode Drop PS C:\> Set-PSSessionConfiguration -Name Test -TransportOption $o

PS C:\> $o = New-PSTransportOption -OutputBufferingMode Drop

PS C:\> Set-PSSessionConfiguration -Name Test -TransportOption $o

Локальные отложенные сессии

«Loopback sessions» или «local sessions» являются сессиями PSSession которые начинаются и заканчиваются на одном и том же компьютере. Как и другие PSSession активированные по сети локальные сессии поддерживают удаленное подключение (с локальным компьютером), так что вы можете отключаться и подключаться к локальной сессий.

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

Тем не менее, если вы используете параметр EnableNetworkAccess в командлетах New-PSSession, Enter-PSSession или Invoke-Command, то локальная сессия создается с интерактивным маркером безопасности. Интерактивный маркер безопасности позволяет использовать команды, которые работают в локальной сессии, и получают данные с других компьютеров.

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

Ожидание заданий в отложенных сессиях

Командлет Wait-Job ждёт, пока работа команд не будет завершена, после этого отображает командную строку или выполняется следующая команда. По умолчанию Wait-Job отвечает, если сессия в которой задание выполняется отключена. Чтобы командлет Wait-Job ждал пока сесия не переподключиться (в открытом состоянии), используется параметр Force. Для получения дополнительной информации см Wait-Job.

Надёжность сессий и непреднамеренное разъединение

Иногда, сеанс с PSSession может быть непреднамеренно разорван из-за компьютерного сбоя или сбоя в работе сети. Windows PowerShell пытается восстановить сеанс с PSSession, но успешность его попыток зависит от тяжести и продолжительности причины сбоя.

При непреднамеренном отключении сессия PSSession может перейти в состояние Broken или Closed, но она также может быть в состоянии Disconnected. Если значени сессии State в состоянии Disconnected, то для управления сессией можно использовать те же методы, как если бы сессия была отключена намеренно. Например, можно использовать командлет Connect-PSSession чтобы подключиться к сессии и командлет Receive-PSSession, чтобы получить результат команд, которые выводились во время, когда сеанса был отключен.

Если закрыть или выйти из сеанса в котором была создана PSSession, в то время как команды в PSSession работают, Windows PowerShell будет поддерживать PSSession в состоянии Disconnected на удаленном компьютере. Если закрыть или выйти из сеанса в котором была создана PSSession, но ни одна из команд не работала в PSSession, Windows PowerShell не будет пытаться сохранить PSSession.

coolcode.ru

Управление настройками сети с помощью PowerShell

Несмотря на то, что PowerShell доступен уже более пяти лет, для многих он все еще остается “синей командной строкой” – это и послужило основной причиной выбрать в качестве темы ежедневные сценарии администратора Windows Server.

Почему стоит обратить внимание на PowerShell, а не использовать привычный cmd? PowerShell мощный инструмент автоматизации, и в ряде сценариев он просто незаменим.

Не стоит забывать, что PowerShell также доступен и через веб а это значит что в случае необходимости Вы сможете работать с iOS, OS X, Windows Phone и Android устройств.

Большинство сетевых командлетов находятся в группе Net*

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

Get-Help Get-NetIPAddress

Также нелишним будет ознакомиться с примерами использования:

Get-Help Get-NetIPAddress -Examples

Теперь я приведу несколько примеров, которые будут актуальны практически для каждого, кто работает с Windows Server:

Get-NetAdapterHardwareInfo

Теперь посмотрим на командлеты клиента DNS:

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

Get-DnsClientCache Clear-DnsClientCache

Get-DnsClientCache

Clear-DnsClientCache

А если у Вас есть что-то в файле hosts это будет видно:

Get-DnsClientServerAddress

Теперь еще несколько полезных командлетов:

это знакомый всем ping, в примере полезные флаги Count и BufferSize:

покажет доступность хоста, с флагом TraceRoute результаты трассировки, а с флагом Port доступ к порту (у этого командлета есть алиас TNC что весьма удобно):

это не менее знакомый nslookup, в примере показаны наиболее востребованные флаги Type и Server:

перезапускает сетевой адаптер:

Под конец статьи я расскажу о том, что чаще всего спрашивают – “Как настроить сетевое подключение ОС через PowerShell”:

Вариантов несколько, самый древний и известный это использование netsh:

Для этого открываем cmd.exe с правами администратора и смотрим какие интерфейсы присутствуют в системе:

netsh interface ipv4 show interfaces

Записываем номер Idx адаптера, который будем настраивать. Теперь зададим основные настройки:

netsh interface ipv4 set address name=”%ID%” source=static address=%ip% mask=%mask% gateway=%gate%

.. и укажем DNS:

netsh interface ipv4 add dnsserver name=”%ID%” address=%DNS% index=1

Для второго DNS необходимо указать index=2 Если нужно вернуть настройки в DHCP достаточно выполнить следующее:

netsh interface ipv4 set address name=”%ID%” source=dhcp

Вот как это выглядит:

Второй способ, это sconfig , он прост и понятен:

Теперь посмотрим как настроить сетевое подключение с помощью PowerShell:

New-NetIPAddress -InterfaceIndex 12 -IPAddress %ip% -PrefixLength %mask% -DefaultGateway %gate%

Set-DnsClientServerAddress -InterfaceIndex 12 -ServerAddress ("%ip%","%ip%")

Чтобы вернуть настройки на DHCP нужно выполнить:

Set-NetIPInterface -Dhcp Enabled

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

По-прежнему только через GUI можно решать некоторые задачи, а некоторые просто удобнее и быстрее.

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.

kagarlickij.com

Дистанционное взаимодействие в среде PowerShell 2.0 | Windows IT Pro/RE

Разработка оболочки PowerShell 1.0 стала настоящим прорывом в развитии средств управления и автоматизации Windows XP, а также более поздних версий платформы ОС Windows. Базирующаяся на платформе. NET Framework технология PowerShell 1.0 включает в себя единообразную структуру команд (cmdlets), она наделена мощными встроенными средствами форматирования выходных данных и обеспечивает значительное повышение доступности других технологий, и прежде всего — инструментария управления Windows (WMI). Однако, хотя некоторые составные команды PowerShell 1.0 и объекты. NET могут подключаться к удаленным компьютерам, эта функция реализуется дифференцированно, в зависимости от конкретного случая. Команды, поддерживающие удаленные соединения, имеют параметр -ComputerName; кроме того, при установлении соединений они используют либо вызовы удаленных процедур (RPC), либо модель DCOM.

Во многих ситуациях RPC и DCOM хорошо справляются с задачами управления, однако при выполнении процедур диагностики и при выявлении причин неполадок порой возникают проблемы. К примеру, команда Get-Service может считывать данные служб с удаленного компьютера с помощью параметра -ComputerName, однако эта команда не имеет параметра -Credential, и потому для ее выполнения следует зарегистрироваться с учетной записью, имеющей разрешение на доступ к удаленной системе.

Но уже в версии Windows PowerShell 2.0 реализован альтернативный механизм подключения к удаленным компьютерам, именуемый remoting (удаленное взаимодействие). Этот механизм использует средства службы дистанционного управления Windows (Windows Remote Management, WinRM). Он обеспечивает подключение к удаленному компьютеру, а также запуск команд, выполняемых на этом удаленном компьютере. Поясню сказанное на примере. Средства подключения к удаленному рабочему столу относятся к графическому интерфейсу пользователя так же, как удаленное взаимодействие к командной строке оболочки PowerShell. Когда вы запускаете составную команду с использованием механизма удаленного взаимодействия, команда фактически выполняется на удаленном компьютере, но полученные результаты вы можете видеть на локальной машине.

Где можно получить Windows PowerShell 2.0

Оболочка PowerShell 2.0 и служба WinRM входят в состав систем Windows 7 и Windows Server 2008 R2, так что, если вы используете эти операционные системы, нет необходимости устанавливать данные компоненты. Если же вы работаете с системами Windows Vista SP2, Windows XP SP3, Windows Server 2008 SP2 или Windows Server 2003 SP2, вам придется загрузить и установить пакет Windows Management Framework Core (support.microsoft.com/kb/968930).

Включение функции удаленного взаимодействия

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

Должна быть активирована служба WinRM.
Должен быть установлен прослушиватель WinRM, который принимает соединения с одного или нескольких IP-адресов.
Сетевой экран Windows должен быть сконфигурирован таким образом, чтобы появилась возможность установления соединений через WinRM.
Должен быть включен и надлежащим образом сконфигурирован сеанс PowerShell.

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

Чтобы пользователи могли как можно скорее приступить к работе, разработчики Microsoft PowerShell создали команду Enable-PSRemoting, обеспечивающую автоматическую настройку упомянутых компонентов. Эту настройку нужно выполнять не на машине, с которой вы будете осуществлять удаленное взаимодействие, а на компьютере, к которому вы будете обращаться дистанционно. Выполнять команду Enable-PSRemoting можно лишь в в том случае, если вы работаете с оболочкой PowerShell с правами администратора. Если вы работаете с машинами Windows Vista, Server 2008 и более поздних версий, правой кнопкой мыши щелкните на значке PowerShell и в раскрывшемся меню выберите пункт Run as administrator. Если вы запустите команду Enable-PSRemoting с параметром -Force, при ее выполнении система не будет обращаться к вам за разрешением на выполнение каждого этапа конфигурации. Чтобы получить более подробные сведения о составной команде Enable-PSRemoting, выполните команду

Get-Help Enable-PSRemoting

Выполнение одной команды на удаленном компьютере

Самый простой способ подключиться к среде PowerShell на удаленном компьютере — воспользоваться командой Enter-PSSession. По умолчанию эта команда выполняется с параметром -ComputerName, поэтому при ее вводе с клавиатуры данный параметр можно не указывать. К примеру, для установления соединения с удаленным компьютером с именем rigel надо ввести с клавиатуры

PS C:\> Enter-PSSession rigel

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

После того как вы введете дистанционный сеанс, синтаксис приглашения PowerShell изменится. Теперь оно будет включать в себя заключенное в квадратные скобки имя удаленного компьютера; это будет означать, что вы установили соединение с удаленным компьютером. В данном случае приглашение будет выглядеть так:

[rigel]: PS C:\>

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

[rigel]: PS C:\> Get-ChildItem C:\

команда Get-ChildItem будет выполнена на удаленной машине. Ее выходные данные будут содержать имена файлов и папок, хранимых в накопителе C удаленного компьютера. Чтобы завершить сеанс удаленного взаимодействия, воспользуйтесь командой Exit-PSSession

[rigel]: PS C:\> Exit-PSSession

Выполнение блока сценария (Scriptblock) на удаленном компьютере

Удаленное взаимодействие с помощью PowerShell позволяет выполнять на удаленном компьютере блок сценария, или scriptblock (то есть блок кода PowerShell, заключенный в фигурные скобки). Для этого нужно воспользоваться командой Invoke-Command с параметром -ComputerName. К примеру, в команде, отображенной на экране 1, я использовал команду Invoke-Command, с тем чтобы выполнить Get-ChildItem на удаленном компьютере. Просматривая экран 1, обратите внимание на то, что для установления соединения с удаленным компьютером перед тем, как запустить блок сценария, я не использовал команду Enter-PSSession. Команды Enter-PSSession и Invoke-Command — это два различных метода удаленного взаимодействия.

Экран 1. Выполнение блока сценария на удаленном компьютере

Первым параметром команды Invoke-Command является параметр -ScriptBlock; он указывает на код, который вы собираетесь выполнить. На экране 1 я опустил имя параметра -ScriptBlock, поскольку указывать его необязательно. Параметр -ComputerName содержит имя удаленного компьютера. Как можно увидеть в выходных данных команды Get-ChildItem, среда PowerShell для удобства оператора даже указывает имя удаленного компьютера в столбце PSComputerName выходных данных.

Выполнение блока сценария на нескольких удаленных компьютерах

Блок сценария можно выполнять и на нескольких удаленных компьютерах. Это называется конфигурацией «один ко многим» или веерным развертыванием. На экране 1 параметр -ComputerName команды Invoke-Command содержит одно имя, однако в него можно включать и несколько имен компьютеров. Так, команда

PS C:\> Invoke-Command {Get-ChildItem env: co*} -Computer titan, rigel

обеспечивает выполнение команды Get-ChildItem на двух удаленных компьютерах. В тексте статьи данная команда разбита на несколько строк, однако в консоли PowerShell ее следует вводить одной строкой. То же касается и других команд, разделенных на несколько строк. Так же, как и на экране 1, столбец PSComputerName в выходных данных будет содержать имена компьютеров.

Выполнение блока сценария в фоновом режиме

Среда PowerShell 2.0 дает возможность выполнять фоновые задания, то есть оператор может запускать команду в фоновом режиме. Такая возможность полезна при запуске команд, выполнение которых требует много времени.

Чтобы запустить фоновое задание на локальном компьютере, можно воспользоваться командой Start-Job. Но надо сказать, что данная команда не имеет параметра -ComputerName, а это значит, что ее нельзя использовать для выполнения фонового задания на удаленной машине. Вместо этого вам нужно будет выполнить команду Invoke-Command с параметром -AsJob. Так, верхняя команда на экране 2 инициирует выполнение блока сценария в виде фонового задания на удаленном компьютере titan. После того как я ввел эту команду, на экране сразу же появилось приглашение: оболочка PowerShell отправила блок сценария для выполнения на удаленный компьютер и после этого вернула мне управление. В предупреждении говорится, что выполненная команда не уместилась в окне консоли и потому не была включена в выходные данные. Если бы окно консоли у меня было шире, средство форматирования оболочки PowerShell включило бы команду в перечень выходных данных. В столбцах Id и Name указывается задание (его идентификатор и понятное имя соответственно), а в столбце State указывается, в каком состоянии находится задание: выполняется, приостановлено или завершено. В столбце HasMoreData содержится информация, свидетельствующая о том, что извлечены все данные, касающиеся того или иного задания, или что задание содержит больший объем сведений, которые следует извлечь.

Экран 2. Выполнение блока сценария в фоновом режиме на удаленном компьютере

Чтобы установить, завершено ли выполнение фонового задания, вы можете выполнить команду Get-Job, как показывает вторая команда на экране 2. Если при этом вы не используете каких-либо параметров, Get-Job проверяет состояние всех заданий, запущенных в ходе текущего сеанса. Если у вас выполняется несколько заданий одновременно, можете использовать такие параметры, как -Id или -Name, для указания на то, какое именно задание вы хотите проверить. Когда выполнение фонового задания завершится, столбец State выходных данных будет иметь значение Completed.

Для считывания результатов выполнения фонового задания можно использовать команду Receive-Job. Эта команда, как и команда Get-Job, возвращает выходные данные всех заданий, запущенных в ходе текущего сеанса, если вы не использовали параметр для указания на то, какое именно задание вас интересует. Так, последняя команда на экране 2 включает в себя параметр -Id, который указывает на то, что необходимо получить выходные данные о задании с идентификатором 9. Я опустил имя параметра -Id, поскольку его указывать необязательно. На экране 3 отображены последние строки выходных данных, касающихся выполнения рассматриваемого дистанционного фонового задания.

Экран 3. Образец результатов выполнения фонового задания на удаленном компьютере

Создание сеансов PowerShell

Приведенные выше примеры показывают, как получить доступ к приглашению PowerShell на удаленной машине и как выполнять команды на удаленных компьютерах. Но я пока не упоминал о том, что удаленное взаимодействие всегда осуществляется в контексте сеанса. Сеанс — это, скажем так, место обитания PowerShell. Когда вы открываете окно консоли PowerShell или окно интегрированной среды сценариев (ISE) PowerShell, вы создаете сеанс. Без использования средств удаленного взаимодействия все сеансы выполняются на локальном компьютере и не зависят друг от друга. Во всех приведенных выше примерах удаленного взаимодействия создаются временные сеансы, которые автоматически прекращаются по завершении удаленного взаимодействия. Кроме того, существует возможность создавать экземпляры сеансов удаленного взаимодействия и повторно использовать их. Такой подход гораздо эффективнее в случаях, когда необходимо обращаться к удаленным компьютерам более одного раза.

Для создания новых сеансов используется команда New-PSSession с параметром -ComputerName. Имя этого параметра в командах можно опускать. Так, команда

C:\> $sessions = New-PSSession phineas, ferb, perry

создает три сеанса на трех компьютерах с именами phineas, ferb и perry. Вы можете просмотреть эти сеансы, создав переменную $sessions. Для этого в командной строке нужно ввести имя

$sessions

и нажать клавишу ввода. Параметр -Session команды Invoke-Command поддерживает объекты session, созданные с помощью команды New-PSSession, поэтому далее вы можете использовать команду, подобную следующей:

C:\> Invoke-Command {Get-ChildItem} -session $sessions

Эта команда выполняет команду Get-ChildItem на машинах phineas, ferb и perry, но не разрывает соединения. Вы можете добавить параметр -AsJob и выполнить команду в фоновом режиме:

C:\> Invoke-Command {Get-ChildItem} -session $sessions -asjob

Далее можно использовать команды Get-Job и Receive-Job для проверки состояния задания и получения его результатов.

Новый подход к работе

Удаленное взаимодействие с помощью средств PowerShell — это новый мощный механизм выполнения команд на удаленных компьютерах. Надеюсь, эта статья подвигнет вас на исследование новых возможностей. Более подробные сведения об удаленном взаимодействии, включая проблемы диагностики, можно найти в справочных темах PowerShell about_Remote по адресу technet.microsoft.com/en-us/library/dd347616.aspx.

Билл Стюарт ([email protected]) — системный и сетевой администратор компании French Mortuary, Нью-Мехико

www.osp.ru

Создание удаленных сессий в PowerShell 2.0 | Windows IT Pro/RE

Когда я начал использовать PowerShell, я увлекся командой Get-Service и заметил, что у нее есть параметр -ComputerName. Не означает ли это, что можно подключиться к службе и с других компьютеров? После проведения ряда экспериментов я обнаружил, что это как раз то, что написано. Я заинтересовался и принялся искать параметры -ComputerName у других команд. И расстроился, когда выяснил, что их было только несколько.

PowerShell обеспечивает два типа удаленного взаимодействия: удаленное взаимодействие один к одному (1:1) и удаленное взаимодействие один к нескольким (1:n). Прежде чем рассказать о них, хочу пояснить некоторые основы.

Основы удаленного взаимодействия в PowerShell

Удаленное взаимодействие PowerShell работает почти как Telnet и другие старые технологии удаленного управления. Когда вы запускаете команду, она на самом деле запускается на удаленном компьютере. Все, что возвращается на ваш компьютер, является результатом работы этой команды. В отличие от Telnet или Secure Shell (SSH), PowerShell использует новый протокол системы связи, который называется Web Services for Management (WS-Management). Протокол действует поверх HTTP или HTTP Secure (HTTPS), что облегчает прокладывание маршрута через брандмауэры, если это необходимо, поскольку протокол использует только один порт для установления связи. Реализация WS-Management от Microsoft идет в форме фоновой службы, которая называется Windows Remote Management. WinRM устанавливается вместе с PowerShell 2.0 и запускается по умолчанию на серверах, подобных Windows Server 2008 R2. На Windows 7 она устанавливается по умолчанию, но не активируется. Необходимо активировать WinRM на тех компьютерах, на которые вы хотите послать команду. Компьютер, за которым вы находитесь физически, не нуждается в запуске службы WinRM.

Все команды PowerShell производят объекты в качестве выходных данных. Когда вы запускаете команду удаленно, ее выходные данные нужно облечь в форму, которую можно легко передавать по сети, используя протокол HTTP или HTTPS. Так, PowerShell автоматически преобразует выходные объекты в файлы XML, которые передаются по сети. Достигнув вашего компьютера, они преобразовываются обратно в объекты, с которыми может работать PowerShell. Однако эти преобразованные обратно объекты на самом деле являются мгновенными снимками. Они не могут обновлять сами себя ежеминутно. Таким образом, если вы должны добраться до объектов, которые представляют собой процессы, запускаемые на удаленном компьютере, то полученный результат будет верен только для конкретного промежутка времени, в течение которого эти объекты были сгенерированы. Значения, такие как использование памяти и процессора, не изменятся. Более того, вы не сможете заставить преобразованные обратно объекты сделать что-либо. Например, вы не можете приказать объекту остановить самого себя. Это основное ограничение удаленного взаимодействия, но оно не помешает вам работать и выполнять интересные задачи.

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

Как ваш компьютер (он же локальный компьютер) и один из тех, которым вы хотите послать команду (он же удаленный компьютер), должны работать с Windows PowerShell 2.0? Windows XP является устаревшей версией Windows, на которую вы можете установить PowerShell 2.0. Таким образом, старая версия тоже может принимать участие в удаленной сессии.
В идеале локальный и удаленный компьютеры должны быть членами одного домена или членами доверенных/доверяющих доменов. С системой удаленного взаимодействия можно работать и вне домена, но это сложно, и здесь я об этом рассказывать не буду. Чтобы узнать больше об этом сценарии, обратитесь к разделу PowerShell Help, где говорится о Remote_Troubleshooting.

Обзор WinRM

Теперь перейдем к WinRM, поскольку вам необходимо задавать настройки этой службы для запуска удаленного взаимодействия. Опять повторюсь, требуется только задать настройки удаленного взаимодействия WinRM и PowerShell на удаленном компьютере. В большинстве сред, в которых я работал, администраторы активировали систему удаленного взаимодействия на каждом компьютере, работающем с версиями XP или более новыми. Это дает возможность проникать в настольные и портативные компьютеры незаметно, что может быть очень полезным (это означает, что пользователи таких компьютеров не будут знать, что вы делаете).

Нельзя сказать, что WinRM представляет собой что-то особенное для PowerShell. WinRM может прокладывать трафик к нескольким административным приложениям. По существу, WinRM действует как диспетчер. Когда трафик появляется, WinRM решает, какое приложение должно взаимодействовать с ним, и помечает его именем приложения-адресата. Принимающее приложение должно зарегистрироваться в WinRM, таким образом WinRM сможет прослушивать входящий трафик от его имени. Другими словами, вам нужно не только активировать WinRM, но и зарегистрировать Power Shell как конечную точку для WinRM.

Самым простым способом выполнения обеих задач является запуск PowerShell от имени администратора и выполнение команды Enable-PSRemoting. Вы можете посмотреть руководство по другой команде, которая называется Set-WSManQuickConfig. Нет нужды запускать команду. Это сделает за вас Enable-PSRemoting, и она же выполняет еще несколько шагов, которые необходимы для установления удаленного взаимодействия и работы. В сущности, команда Enable-PSRemoting запускает службу WinRM, задает ее настройки для запуска автоматически, регистрирует PowerShell как конечную точку и даже устанавливает исключения в Windows Firewall для того, чтобы разрешить входящий трафик WinRM.

Если вам не хочется обходить все компьютеры ради активации удаленного взаимодействия, можно задействовать объект групповой политики Group Policy Object (GPO). Необходимые настройки GPO встроены в контроллеры домена Windows Server 2008 R2. Просто откройте GPO и идите по маршруту Computer Configuration\

Administrative Templates\Windows Components. Внизу списка вы найдете как Remote Shell, так и Windows Remote Management (WRM), настройки которых нужно задать. Раздел Help о проблемах системы удаленного взаимодействия (Remote_Troubleshooting) даст вам детальные инструкции о том, как это сделать. Просмотрите разделы How to Enable Remoting in an Enterprise и How to Enable Listeners by Using a Group Policy в Help.

WinRM 2.0 (который применяется PowerShell) по умолчанию использует порт TCP 5985 для HTTP и порт 5986 для HTTPS. Это гарантирует, что WinRM не будет конфликтовать с локально установленными веб-серверами, которые настроены на прослушивание портов 80 и 443. Вы можете задать настройки WinRM для использования альтернативных портов, но я не рекомендую этого делать. Ели вы оставите эти порты, все команды удаленного доступа PowerShell будут работать нормально. Если вы измените эти порты, вам придется всегда указывать альтернативный порт при запуске команды удаленного доступа. Это означает, что вам придется больше печатать. Если вам крайне необходимо изменить порт, можете ввести команду:

Winrm set winrm/config/ listener? Address=* +Transport=HTTP @{Port="1234"}

Цифры 1234 означают порт, который вам нужен. Здесь эта команда написана в несколько строк, но вам нужно вводить ее в одну строку. То же самое касается и всех других команд, описанных в статье. Если необходимо использовать HTTPS вместо http, вы можете видоизменить эту команду, чтобы настроить новый порт HTTPS. Должен признаться, что есть способ задать настройки WinRM на локальных компьютерах для того, чтобы задействовать альтернативные порты по умолчанию. Таким образом, вам не нужно постоянно определять альтернативный порт, когда вы запускаете команду удаленного доступа. Но давайте поработаем с настройками по умолчанию, заданными Microsoft.

Если покопаться в настройках GPO в Remote Shell, вы заметите, что можете задать, например, насколько долго удаленная сессия будет оставаться неактивной до того, как сервер прервет ее; как много одновременно действующих пользователей могут обращаться к удаленному серверу за один раз; как много памяти и процессов каждая удаленная оболочка может использовать; максимальное количество удаленных оболочек, которые пользователи могут открывать за один раз. Эти настройки помогут убедиться, что ваши серверы не перегружены забывчивыми администраторами. Однако по умолчанию необходимо быть администратором, чтобы использовать удаленное взаимодействие, поэтому вам не стоит беспокоиться об обычных пользователях, засоряющих ваши серверы.

Удаленное взаимодействие 1:1

Используя удаленное взаимодействие 1:1, вы, по существу, получаете доступ к командной строке на одном удаленном компьютере. Любые команды, которые вы даете, запускаются прямо на удаленном компьютере, а вы видите результаты в окне командной строки. Отчасти это похоже на использование Remote Desktop Connection, если не считать того, что вы ограничены средой командной строки PowerShell. Система удаленного взаимодействия PowerShell использует часть ресурсов, которые требует Remote Desktop, поэтому она оказывает намного меньшее воздействие на ваши серверы.

Для того чтобы установить соединение 1:1 с удаленным компьютером, названным Server-R2, нужно запустить

Enter-PSSession -Computername Server-R2

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

[server-r2] PS C:\>

Часть [server-r2] информирует вас о том, что все, что вы делаете, происходит на Server-R2. После этого вы можете запустить любые команды, какие хотите. Вы даже можете импортировать любые модули и добавить расширения PowerShell (PSSnapins), которые будут располагаться на удаленном компьютере.

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

Если у вас есть сценарий PowerShell для вашего профиля на удаленном компьютере, он не будет запускаться, когда вы подсоединитесь, используя систему удаленного доступа. Проще говоря, профили являются пакетом команд, которые автоматически запускаются каждый раз, когда вы открываете окно командной строки. Они используются для автоматической загрузки расширений, модулей и тому подобного.
Вы ограничены политикой Execution Policy удаленного компьютера. Скажем, политика вашего компьютера устанавливается на RemoteSigned так, что вы можете запускать локальные неподписанные сценарии. Если политика удаленного компьютера установлена в Restricted (настройка по умолчанию), она не позволит запускать никакие сценарии, когда вы взаимодействуете удаленно.

Многие команды PowerShell идут в парах: одна делает нечто, другая — противоположное этому. В нашем случае Enter-PSSession подсоединяет вас к удаленному компьютеру, а Exit-PSSession закрывает это соединение. Exit-PSSession не нужны никакие параметры. После запуска удаленное соединение закрывается, и приглашение вашего окна командной строки возвращается обратно к нормальному виду. А что если вы забудете запустить Exit-PSSession? Не беспокойтесь. PowerShell и WinRM способны выяснить, что вы сделали, и закрыть в случае необходимости удаленное соединение.

Хочу дать один совет. Когда вы подсоединяетесь к удаленному компьютеру, не запускайте на нем Enter-PSSession до тех пор, пока полностью не осознаете, что вы делаете. Например, вы работаете на ComputerА. Вы подсоединяетесь к Server-R2. В строке PowerShell вы запускаете

[server-r2] PS C:\> Enter-PSSession Server-DC4

Теперь Server-R2 содержит открытое соединение с Server-DC4. Это создает «цепь удаленного взаимодействия», которую отследить сложно. Кроме того, ваши серверы без надобности оказываются перегруженными. Могут быть моменты, когда вы должны будете делать это (например, Server-DC4 находится за брандмауэром и вы не можете получить к нему прямой доступ, поэтому в качестве посредника вам нужно использовать Server-R2). Однако общее правило состоит в следующем: старайтесь избегать цепочек удаленного взаимодействия.

Удаленное взаимодействие 1:n

Одна из самых интересных вещей в PowerShell — это удаленное взаимодействие 1: n. Оно позволяет вам отсылать команды на несколько удаленных компьютеров одновременно — полномасштабные распределенные вычисления. Каждый компьютер по отдельности будет выполнять команду и отсылать вам результаты. Все делается при помощи команды Invoke-Command в таком виде:

Invoke-Command -ComputerName Server-R2, Server-DC4, Server12 -Command {Get-EventLog Security -Newest 200 | Where {$_.EventID -eq 1212}}

Команда во внешних фигурных скобках передается на все три удаленных компьютера. По умолчанию PowerShell может разговаривать с 32 компьютерами сразу. Если вы определяете более чем 32 компьютера, они будут выстроены в очередь. Затем, когда один компьютер завершает работу, команду выполняет следующий. Если у вас действительно скоростная сеть и мощные компьютеры, вы можете увеличить их количество, используя параметр ThrottleLimit команды. Прочитать о том, как использовать этот параметр в Invoke-Command, вы можете на странице Help.

Единственный параметр, которого вы не увидите на странице Help этой команды, — параметр Command. Он, как я уже показал, работает прекрасно. Параметр Command является псевдонимом или кратким именем для параметра ScriptBlock, который указан на странице Help. Для меня проще использовать Command, поэтому я склонен задействовать именно его вместо ScriptBlock, однако они работают одинаково.

Если вы прочитали страницу Help для Invoke-Command внимательно, вы также заметили параметр, который позволяет указывать файл сценария, а не команду. Параметр FilePath позволяет посылать сценарий на удаленные компьютеры; это означает, что вы можете автоматизировать некоторые сложные задачи, а каждый компьютер будет выполнять свою долю работы.

Теперь остановимся на параметре Computer Name. В примере кода Invoke-Command у меня был список имен компьютера, разделенный запятыми. Если у вас много компьютеров, то вы, возможно, не хотите печатать их имена каждый раз, когда подсоединяетесь к ним. Вместо этого вы можете создать текстовый файл, который содержит по одному имени компьютера на одной строке, без запятых, кавычек или чего-то еще. Например, если бы ваш текстовый файл был назван webservers.txt, вы бы использовали такой код:

Invoke-Command -Command { dir } -ComputerName (Get-Content webservers.txt)

Круглые скобки заставляют PowerShell выполнять сначала команду Get-Content — это похоже на то, как работают круглые скобки в математике. Затем результаты Get-Content вкладываются в параметр -ComputerName.

Возможен также запрос имени компьютера в Active Directory, но это сложнее. Для того чтобы найти компьютер, вы можете использовать команду Get-ADComputer, но вы не вставите эту команду в круглые скобки, как делали это в Get-Content. Почему нет? Get-Content выдает простые текстовые строки, тогда как Get-ADComputer производит объекты типа «компьютер». Параметр -ComputerName ожидает строки. Если бы он должен был получать объекты «компьютер», то не знал бы, что с ними делать. Поэтому, если вы хотите использовать Get-ADComputer, вам нужно получить значения из свойства Name компьютерных объектов. Вот так:

Invoke-Command -Command {dir} -ComputerName (Get-ADComputer -Filter * -SearchBase "ou=Sales, dc=company, dc=pri" | Select-Object -Expand Name)

В круглых скобках компьютерные объекты передаются команде Select-Object, а параметр -Expand используется для выяснения свойства Name этих компьютерных объектов. Результат выражения в скобках — это набор имен компьютера, а не компьютерных объектов. Имена компьютеров — это как раз то, что нужно параметру -Computer Name.

Если вы не знакомы с Get-ADComputer, давайте посмотрим, что делает эта команда. Параметр -Filter определяет, что все компьютеры должны быть включены в результаты, а параметр -Search Base предписывает PowerShell, чтобы он начал искать компьютеры в организационной группе Sales (OU) в домене company.pri. Команда Get-ADComputer доступна только в Windows Server 2008 R2 и в Windows 7 после установки набора утилит Remote Server Administration Tools. В этих операционных системах вы запускаете

Import-Module ActiveDirectory

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

Есть кое-что еще!

Все эти примеры были приведены для одноранговых сессий удаленного взаимодействия. Если вы собираетесь восстановить соединение с теми же самыми компьютерами (или компьютером) несколько раз за короткий промежуток времени, вы можете создать повторно используемые, постоянные сессии. Это очень полезно, если соединение требует альтернативных учетных данных, номера порта не по умолчанию или чего-то еще, что требует дополнительных параметров.

Чтобы создать постоянные сессии, нужно использовать команду New-PSSession, затем сохранить их в переменной для легкого доступа. Например, следующий код создает сессию удаленного взаимодействия с тремя компьютерами и сохраняет их в переменной $sessions:

$sessions = New-PSSession -ComputerName One, Two, Three -Port 5555 -Credential DOMAIN\Administrator

Сессии удаленного взаимодействия закрываются автоматически, когда вы закрываете командную оболочку, но до этого времени они могут занимать память и немного загружать процессор на локальной и удаленной системах. Для того чтобы точно закрыть их, вы можете использовать команду Remove-PSSession:

$sessions | Remove-PSSession

Когда вам нужно вновь открыть сессии, вы можете задействовать команду Invoke-Command:

Invoke-Command -Command {dir} -Session $sessions

Или можете применить Enter-PSSession:

Enter-PSSession -Session $session [1]

Заметьте, что в коде Enter-PSSession только одна сессия удаленного взаимодействия открывается повторно. Переменная индекса 1 сообщает PowerShell, что он должен вновь открыть сессию с компьютером, названным Two (индекс отсчитывается с нулевого значения).

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

Дон Джоунз ([email protected]) — технический инструктор по PowerShell (www.windowsitpro.com/go/DonJonesPowerShell), автор более 35 книг. Имеет звание Microsoft MVP

www.osp.ru

Подключение к клиентам Exchange Online с помощью удаленного сеанса Windows PowerShell для партнеров службы разрешений делегированного доступа (DAP)

31.10.2018
Время чтения: 8 мин
Соавторы

Процедуры, описанные в этой статье, предназначены только для партнеров службы разрешений делегированного доступа (DAP). Если вы не являетесь партнером DAP, не используйте эти процедуры.The procedures in this topic are only for Delegated Access Permission (DAP) partners. If you aren't a DAP partner, don't use the procedures in this topic.

Партнеры DAP являются партнерами синдикации и поставщиков облачных решений (CSP). Они часто являются поставщиками сети или телекоммуникационных услуг в других компаниях. Они включают подписки в услуги для своих клиентов. Они владеют партнерскими правами, что автоматически предоставляет разрешение на администрирование от имени (AOBO) их клиентам Office 365, так что они имеют право на администрирование всех своих клиентов и создание отчетов о них.DAP partners are Syndication and Cloud Solution Providers (CSP) partners. They are frequently network or telecom providers to other companies. They bundle subscriptions into their service offerings to their customers. They own a partner tenancy that is automatically granted Administer On Behalf Of (AOBO) permissions to their Office 365customer tenancies so they can administer and report on all of their customer tenancies.

Партнеры DAP могут использовать среду Exchange Online PowerShell, чтобы управлять настройками Exchange Online и получать отчеты Office 365 с командной строки. С помощью Windows PowerShell на локальном компьютере можно создать удаленный сеанс PowerShell с Exchange Online. Эта простая трехэтапная процедура предусматривает ввод учетных данных, настройку необходимых параметров подключения, а также импорт командлетов Exchange Online в локальный сеанс Windows PowerShell для дальнейшего использования.Remote PowerShell allows you to manage your Exchange Online settings from the command line. You use Windows PowerShell on your local computer to create a remote Shell session to Exchange Online. It’s a simple three-step process where you enter your Exchange Online credentials, provide the required connection settings, and then import the Exchange Online cmdlets into your local Windows PowerShell session so that you can use them.

Что нужно знать перед началом работыWhat do you need to know before you begin?

Предполагаемое время для завершения: 5 минут.Estimated time to complete: 5 minutes
Ниже приведены версии Windows, которые можно использовать.You can use the following versions of Windows:
- Windows 10Windows 10
- Windows 8.1Windows 8.1
- Windows Server 2016Windows Server 2016
- Windows Server 2012 или Windows Server 2012 R2Windows Server 2012 or Windows Server 2012 R2
- Windows 7 с пакетом обновления 1 (SP1)*Windows 7 Service Pack 1 (SP1)*
- Windows Server 2008 R2 с пакетом обновления 1 (SP1)*Windows Server 2008 R2 SP1
  
  * Для более ранних версий Windows нужно установить Microsoft.NET Framework 4.5 или более поздней версии, а затем обновленную версию Windows Management Framework 3.0, 4.0 или 5.1 (только одну). Дополнительные сведения см. в статьях Установка .NET Framework, Windows Management Framework 3.0, Windows Management Framework 4.0 и Windows Management Framework 5.1.* For older versions of Windows, you need to install the Microsoft.NET Framework 4.5 or later and then an updated version of the Windows Management Framework: 3.0, 4.0, or 5.1 (only one). For more information, see Installing the .NET Framework, Windows Management Framework 3.0, Windows Management Framework 4.0, and Windows Management Framework 5.1.
Чтобы запускать сценарии, необходимо настроить Windows PowerShell. По умолчанию это приложение не настроено. При попытке подключения появится указанная ниже ошибка.Windows_PowerShell needs to be configured to run scripts, and by default, it isn't. You get the following error when you try to connect:

Files cannot be loaded because running scripts is disabled on this system. Provide a valid certificate with which to sign the files.

Чтобы требовать подпись надежного издателя для всех сценариев PowerShell, загружаемых из Интернета, выполните следующую команду в окне Windows PowerShell с повышенными привилегиями (окно Windows PowerShell, которое открывается с помощью параметра Запуск от имени администратора).To require all PowerShell scripts that you download from the internet are signed by a trusted publisher, run the following command in an elevated Windows PowerShell window (a Windows PowerShell window you open by selecting Run as administrator):
Set-ExecutionPolicy RemoteSigned
Достаточно настроить этот параметр один раз, и вам не придется делать это при каждом подключении.You need to configure this setting only once on your computer, not every time you connect.
Сведения о сочетаниях клавиш, которые можно использовать в процедурах из этой статьи, см. в статье Сочетания клавиш в Центре администрирования Exchange.For information about keyboard shortcuts that might apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.

Подключение к Exchange Online для организаций пользователейConnect to Exchange Online for customer organizations

На локальном компьютере откройте Windows PowerShell и запустите следующую команду.On your local computer, open Windows PowerShell and run the following command.
$UserCredential = Get-Credential
В диалоговом окне Запрос учетных данных Windows PowerShell введите имя пользователя и пароль администратора DAP, а затем нажмите кнопку ОК.In the Windows PowerShell Credential Request dialog box, enter your DAP administrator user name and password, and then click OK.
Замените <доменное имя клиента пользователя> именем клиентского домена, к которому нужно подключиться, и выполните следующую команду.Replace <customer tenant domain name> with the name of the tenant domain that you want to connect to, and run the following command:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=<customer tenant domain name> -Credential $UserCredential -Authentication Basic -AllowRedirection
Ключевой этап этой команды — указание пользователя, отчетные данные о котором нужно получить. Это делается в параметре ConnectionURI, где указывается полное имя исходного домена как значение для параметра ?DelegatedOrg=. Это значение указывает правильную конечную точку Exchange Online PowerShell, к которой нужно подключиться. Удаленный сеанс PowerShell должен подключаться к службе отчетов Office 365 в контексте определенного пользователя при каждом запуске. После подключения к Exchange Online PowerShell запускаются все последующие команды в контексте пользователя, что предоставляет вам доступ ко всем доступным отчетам для пользователя.The key step in this command is specifying which customer to access for the reporting information. You do this in the ConnectionURI parameter, where you provide the FQDN of the initial domain name as the value to the ?DelegatedOrg= parameter. This tells remote Windows PowerShell for Exchange Online PowerShell remote Windows PowerShell the endpoint to connect to. remote Windows PowerShell must connect to Office 365 reporting in the context of a specific customer each time a report is run. After this customer is specified, all of the following commands are run in the context of that customer. This lets the partner to access all the available reports for this customer.
Выполните следующую команду.Run the following command.
Import-PSSession $Session

Примечание

В одной учетной записи можно одновременно запускать до трех сеансов. По завершении настройки отключите удаленный сеанс PowerShell. Если закрыть окно Windows PowerShell, не выполнив отключение сеанса, то можно исчерпать лимит доступных сеансов удаленной среды PowerShell. К тому же, придется дождаться завершения сеанса. Чтобы отключить удаленный сеанс PowerShell, выполните приведенную ниже команду.There is a limit of three simultaneous sessions that can run under one account. Be sure to disconnect the remote Windows PowerShell session when you're finished. If you close the Windows PowerShell window without disconnecting the session, you can use up all the remote Windows PowerShell sessions available to you, and you'll need to wait for the sessions to expire. To disconnect the remote Windows PowerShell session, run the following command. >

Remove-PSSession $Session

Как проверить, что все получилось?How do you know this worked?

После шага 3 командлеты Exchange Online импортируются в локальный сеанс Windows PowerShell, на что указывает индикатор выполнения. Если при этом не возникают ошибки, подключение установлено. Чтобы выполнить быструю проверку, запустите командлет Exchange Online (например, Get-Mailbox) и просмотрите результаты его выполнения.After Step 3, the Exchange Online cmdlets are imported into your local Windows PowerShell session as tracked by a progress bar. If you don't receive any errors, you connected successfully. A quick test is to run an Exchange Online cmdlet—for example, Get-Mailbox —and see the results.

Если возникают ошибки, просмотрите список возможных причин ниже.If you receive errors, check the following requirements:

Распространенная проблема — неправильный пароль. Еще раз повторите три описанные выше действия, уделив особое внимание действию 1 — вводу имени пользователя и пароля.A common problem is an incorrect password. Run the three steps again and pay close attention to the user name and password you enter in Step 1.
Для учетной записи, которую вы используете для подключения к Exchange Online, необходимо включить доступ к удаленному сеансу PowerShell. Дополнительные сведения см. в статье Включение и отключение доступа к Exchange Online PowerShell.The account you use to connect to Exchange Online must be enabled for remote Windows PowerShell. For more information, see Manage Remote PowerShell Access in Exchange Online.
Между клиентским компьютером и службой Exchange Online должен быть открыт порт TCP-порт 80. Вполне вероятно, что он уже открыт, но в этом следует убедиться, если в вашей организации действует политика ограниченного доступа к Интернету.TCP port 80 traffic needs to be open between your local computer and Exchange Online. It's probably open, but it's something to consider if your organization has a restrictive Internet access policy.

Вызов командлета напрямую с помощью команды Invoke-CommandCall the cmdlet directly with Invoke-Command

Импорт удаленного сеанса PowerShell (шаг 3) может занимать много времени, поскольку в нем используются все командлеты Exchange Online. Это может быть проблемой при пакетной обработке (например, если создаются отчеты или выполняется пакетное изменение для разных клиентов). Вместо того чтобы использовать Import-PSSession, вы можете вызывать нужные командлеты напрямую с помощью команды Invoke-Command. Например, чтобы вызвать командлет Get-Milbox, вставьте этот код вместо команды Import-PSSession $Session на шаге 3:Importing a remote Windows PowerShell session can be a lengthy process because it brings in all Exchange Online cmdlets. This can be an issue in batch processing—for example, when you are running reports or making bulk changes for different tenants. As an alternative to using Import-PSSession, you can call cmdlets you want to use directly with Invoke-Command. For example, to call the get-mailbox cmdlet, substitute this syntax for .

Invoke-Command -Session $Session -ScriptBlock {Get-Mailbox}

Дополнительные командлеты для отчетовMore reporting cmdlets

В этом разделе используются командлеты Windows PowerShell. Дополнительные сведения об этих командлетах см. в следующих статьях.The cmdlets that you used in this topic are Windows PowerShell cmdlets. For more information about these cmdlets, see the following topics:

docs.microsoft.com

Включение подключения к удаленному рабочему столу для роли в облачных службах Azure с помощью PowerShell

07/18/2017
Время чтения: 7 мин
Соавторы

С помощью удаленного рабочего стола обеспечивается доступ к рабочему столу экземпляра, работающего в Azure.Remote Desktop enables you to access the desktop of a role running in Azure. Подключение к удаленному рабочему столу позволяет диагностировать и устранять неполадки выполняющегося приложения.You can use a Remote Desktop connection to troubleshoot and diagnose problems with your application while it is running.

В этой статье описывается включение удаленного рабочего стола для ролей облачной службы с помощью PowerShell.This article describes how to enable remote desktop on your Cloud Service Roles using PowerShell. Сведения о компонентах, которые потребуются для выполнения инструкций в этой статье, см. в статье Установка и настройка Azure PowerShell.See How to install and configure Azure PowerShell for the prerequisites needed for this article. В PowerShell используется расширение удаленного рабочего стола, поэтому удаленный рабочий стол можно включить даже после развертывания приложения.PowerShell utilizes the Remote Desktop Extension so you can enable Remote Desktop after the application is deployed.

Настройка удаленного рабочего стола с помощью PowerShellConfigure Remote Desktop from PowerShell

Командлет Set-AzureServiceRemoteDesktopExtension позволяет включить удаленный рабочий стол для всех или некоторых ролей в развернутой облачной службе.The Set-AzureServiceRemoteDesktopExtension cmdlet allows you to enable Remote Desktop on specified roles or all roles of your cloud service deployment. Он позволяет указать имя и пароль пользователя удаленного рабочего стола с помощью параметра Credential , который принимает объект PSCredential.The cmdlet lets you specify the Username and Password for the remote desktop user through the Credential parameter that accepts a PSCredential object.

Если вы используете PowerShell в интерактивном режиме, то можете задать объект PSCredential, вызвав командлет Get-Credentials .If you are using PowerShell interactively, you can easily set the PSCredential object by calling the Get-Credentials cmdlet.

$remoteusercredentials = Get-Credential

Эта команда открывает диалоговое окно, в котором вы сможете в защищенном режиме указать имя и пароль удаленного пользователя.This command displays a dialog box allowing you to enter the username and password for the remote user in a secure manner.

Так как PowerShell используется в сценариях автоматизации, объект PSCredential можно настроить так, чтобы участие пользователя не требовалось.Since PowerShell helps in automation scenarios, you can also set up the PSCredential object in a way that doesn't require user interaction. Сначала необходимо задать надежный пароль.First, you need to set up a secure password. Для начала нужно придумать текстовый пароль и преобразовать его в защищенную строку с помощью командлета ConvertTo-SecureString.You begin with specifying a plain text password convert it to a secure string using ConvertTo-SecureString. Далее следует преобразовать защищенную строку в зашифрованную стандартную строку, используя командлет ConvertFrom-SecureString.Next you need to convert this secure string into an encrypted standard string using ConvertFrom-SecureString. После этого вы можете сохранить зашифрованную стандартную строку в файл с помощью командлета Set-Content.Now you can save this encrypted standard string to a file using Set-Content.

Можно также создать файл с надежным паролем, чтобы не нужно было каждый раз вводить пароль.You can also create a secure password file so that you don't have to type in the password every time. Кроме того, файл с надежным паролем безопаснее, чем обычный текстовый файл.Also, a secure password file is better than a plain text file. Для создания файла надежного пароля используйте эту команду PowerShell:Use the following PowerShell to create a secure password file:

ConvertTo-SecureString -String "Password123" -AsPlainText -Force | ConvertFrom-SecureString | Set-Content "password.txt"

Чтобы создать объект учетных данных из файла с надежным паролем, необходимо считать содержимое файла и преобразовать его обратно в защищенную строку с помощью командлета ConvertTo-SecureString.To create the credential object from the secure password file, you must read the file contents and convert them back to a secure string using ConvertTo-SecureString.

Командлет Set-AzureServiceRemoteDesktopExtension принимает также параметр Expiration , который указывает значение DateTime , определяющее дату и время истечения срока действия учетной записи пользователя.The Set-AzureServiceRemoteDesktopExtension cmdlet also accepts an Expiration parameter, which specifies a DateTime at which the user account expires. Например, можно задать срок действия учетной записи, который истечет через несколько дней.For example, you could set the account to expire a few days from the current date and time.

В этом примере показано, как установить расширение удаленного рабочего стола для облачной службы с помощью PowerShell:This PowerShell example shows you how to set the Remote Desktop Extension on a cloud service:

$servicename = "cloudservice" $username = "RemoteDesktopUser" $securepassword = Get-Content -Path "password.txt" | ConvertTo-SecureString $expiry = $(Get-Date).AddDays(1) $credential = New-Object System.Management.Automation.PSCredential $username,$securepassword Set-AzureServiceRemoteDesktopExtension -ServiceName $servicename -Credential $credential -Expiration $expiry

При необходимости вы также можете указать слот развертывания и роли, для которых необходимо включить удаленный рабочий стол.You can also optionally specify the deployment slot and roles that you want to enable remote desktop on. Если эти параметры не указаны, командлет по умолчанию включит использование удаленного рабочего стола для всех ролей в слоте развертывания рабочей среды .If these parameters are not specified, the cmdlet enables remote desktop on all roles in the Production deployment slot.

Расширение удаленного рабочего стола привязывается к развернутой службе.The Remote Desktop extension is associated with a deployment. В случае создания нового развертывания службы потребуется включить использование удаленного рабочего стола для этого развертывания.If you create a new deployment for the service, you have to enable remote desktop on that deployment. Если необходимо, чтобы использование удаленного рабочего стола включалось всегда, рассмотрите возможность интеграции соответствующих сценариев PowerShell в рабочий процесс развертывания.If you always want to have remote desktop enabled, then you should consider integrating the PowerShell scripts into your deployment workflow.

Подключение к экземпляру роли по протоколу удаленного рабочего столаRemote Desktop into a role instance

Командлет Get-AzureRemoteDesktopFile можно использовать, чтобы добавить удаленный рабочий стол для определенного экземпляра роли облачной службы.The Get-AzureRemoteDesktopFile cmdlet is used to remote desktop into a specific role instance of your cloud service. Можно использовать параметр LocalPath , чтобы скачать RDP-файл на локальный компьютер.You can use the LocalPath parameter to download the RDP file locally. Вы можете также использовать параметр Launch , чтобы открыть диалоговое окно "Подключение к удаленному рабочему столу" для доступа к экземпляру роли облачной службы.Or you can use the Launch parameter to directly launch the Remote Desktop Connection dialog to access the cloud service role instance.

Get-AzureRemoteDesktopFile -ServiceName $servicename -Name "WorkerRole1_IN_0" -Launch

Убедитесь, что расширение удаленного рабочего стола включено в службе.Check if Remote Desktop extension is enabled on a service

Командлет Get-AzureServiceRemoteDesktopExtension показывает, включен ли удаленный рабочий стол в развернутой службе.The Get-AzureServiceRemoteDesktopExtension cmdlet displays that remote desktop is enabled or disabled on a service deployment. Он возвращает имя пользователя удаленного рабочего стола и роли, для которых включено расширение удаленного рабочего стола.The cmdlet returns the username for the remote desktop user and the roles that the remote desktop extension is enabled for. По умолчанию это выполняется в слоте развертывания, и вы можете выбрать слот промежуточного развертывания.By default, this happens on the deployment slot and you can choose to use the staging slot instead.

Get-AzureServiceRemoteDesktopExtension -ServiceName $servicename

Удаление расширения удаленного рабочего стола из службыRemove Remote Desktop extension from a service

Если вы уже включили расширение удаленного рабочего стола в развернутой службе и хотите обновить параметры удаленного рабочего стола, то сначала удалите расширение удаленного рабочего стола.If you have already enabled the remote desktop extension on a deployment, and need to update the remote desktop settings, first remove the extension. Затем снова включите его с новыми параметрами.And enable it again with the new settings. Например, если вы хотите задать новый пароль для учетной записи удаленного пользователя или ее срок действия истек.For example, if you want to set a new password for the remote user account, or the account expired. Данное действие необходимо только для существующих развертываний, в которых включено расширение удаленного рабочего стола.Doing this is required on existing deployments that have the remote desktop extension enabled. К новым развертываниям можно непосредственно применить расширение.For new deployments, you can simply apply the extension directly.

Чтобы удалить расширение удаленного рабочего стола из развернутой службы, используйте командлет Remove-AzureServiceRemoteDesktopExtension .To remove the remote desktop extension from the deployment, you can use the Remove-AzureServiceRemoteDesktopExtension cmdlet. При необходимости можно также указать слот развертывания и роль, для которой необходимо удалить удаленный рабочий стол.You can also optionally specify the deployment slot and role from which you want to remove the remote desktop extension.

Remove-AzureServiceRemoteDesktopExtension -ServiceName $servicename -UninstallConfiguration

Примечание

Чтобы полностью удалить конфигурацию расширения, выполните командлет remove с параметром UninstallConfiguration .

Параметр UninstallConfiguration удаляет все конфигурации расширения, примененные к службе. Каждая конфигурация расширения связана с конфигурацией службы. Вызов командлета remove без параметра UninstallConfiguration разорвет связь развертывания с конфигурацией расширения, фактически удаляя это расширение. Однако конфигурация расширения будет по-прежнему связана со службой.

Дополнительные ресурсыAdditional resources

Настройка облачных службHow to Configure Cloud Services

docs.microsoft.com

PowerShell. О требованиях к инраструктуре для работы дистанционного подключения. (about_Remote_Requirements) — Клёвый код

В этом разделе описываются требования к инфраструктуре, учётным записям и ресурсам для создания удаленных соединений и выполнения удаленных команд в Windows PowerShell. В данном разделе также содержится инструкция по настройки инфраструктуры для работы удаленных операций.

Примечание: Многие командлеты (в том числе командлеты Get-Service, Get-Process, Get-WMIObject, Get-EventLog, и Get-WinEvent) могут получать объекты с удаленных компьютеров с помощью методов для извлечения объектов Microsoft .NET Framework. Они не используют инфраструктуру удаленного взаимодействия Windows PowerShell. Требования в этом документе не распространяются на эти команды.

Чтобы найти командлеты, которые имеют параметр ComputerName, и не используют Windows PowerShell Remoting, можно воспользоваться командлетом Get-Command.

Get-Command -ParameterName ComputerName

Системные требования

Для запуска удаленных сеансов с поддержкой возможностей Windows PowerShell 3.0, локальные и удаленные компьютеры должны иметь следующее компоненты:— Windows PowerShell 3.0 или более позднюю версию— Платформу Microsoft .NET Framework 4.0 или более позднюю версию— Windows Remote Management 3.0

Для запуска удаленных сеансов с возможностями Windows PowerShell 2.0, локальные и удаленные компьютеры должны иметь следующее компоненты:— Windows PowerShell 2.0 или более позднюю версию— Платформа Microsoft .NET Framework 2.0 или более позднюю версию— Windows Remote Management 2.0

Можно создавать удалённые сеансы связи между компьютерами под управлением Windows PowerShell 2.0 и Windows PowerShell 3.0. Тем не менее, возможности удалённых соединений которые работают только на Windows PowerShell 3.0, например такое как способность переподключаться к сессиям, доступны только тогда, когда оба компьютеры работают под управлением Windows PowerShell 3.0.

Чтобы посмотреть номер версии Windows PowerShell установленной на текущем компьютере, можно воспользоваться автоматической переменной $PSVersionTable.

Windows Remote Management (WinRM) 3.0 и Microsoft .NET Framework 4.0 включены в Windows 8, Windows Server 2012, и новые выпуски операционных системы Windows. В более поздних операционных системах надо установить WinRM 3.0 он входит в Management Framework 3.0 для Windows. Если компьютер не имеет требуемой версии WinRM или Microsoft .NET Framework, произойдёт сбой установки.

Права пользователя

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

Разрешения необходимые для создания сессий и выполнения команд на удаленном компьютере (или в удаленной сессии на локальном компьютере) устанавливаются конфигурацией сеанса (также известной как «endpoint») на удаленном компьютере, к которому подключается сессия. В частности, дескриптор безопасности конфигурации сеанса определяет, кто имеет доступ к конфигурации сеанса и кто может использовать его для подключения.

По умолчанию, дескрипторы безопасности конфигураций сеансов Microsoft.PowerShell, Microsoft.PowerShell32 и Microsoft.PowerShell.Workflow, разрешают доступ только для членов группы администраторов.

Если текущий пользователь не имеет разрешения на использование конфигурации сеанса, то команда запускающая команды (используется временная сессия) или создание постоянного сеанса на удаленном компьютере не удастся. Пользователь может использовать параметр командлетов ConfigurationName, которые создают сеансы с помощью другой конфигурации сеанса, если таковые имеются.

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

Для получения дополнительной информации о конфигурациях сеансов см about_Session_Configurations.

Сетевое окружение Windows

Начиная с Windows PowerShell 3.0, командлетом Enable-PSRemoting можно включить удаленное взаимодействие на клиентских и серверных операционных систем, в домене и общественных сетях.

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

На клиентских версиях Windows в частных и доменных сетях, по умолчанию командлет Enable-PSRemoting создает правило брандмауэра, которое позволяет неограниченный удаленный доступ.

Чтобы включить удаленное взаимодействие на клиентских версиях Windows с сетями общего пользования, используется параметр SkipNetworkProfileCheck командлета Enable-PSRemoting. Это создаст правило брандмауэра, которое разрешает удаленный доступ только с компьютеров в локальной подсети.

Чтобы убрать ограничение только локальной подсетью и разрешить удаленный доступ из всех мест, в клиентских и серверных версиях Windows, используется командлет Set-NetFirewallRule из модуля NetSecurity. Надо выполнить следующую команду:

Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any

В Windows PowerShell 2.0, на серверных версиях Windows, Enable-PSRemoting создает правила брандмауэра, которое разрешает удаленный доступ на все сети.

В Windows PowerShell 2.0, на клиентских версиях Windows, Enable-PSRemoting создает правила брандмауэра только для частных и доменных сетей. Если сетевое расположение является публичным, Enable-PSRemoting не выполнится.

Запуск от имени администратора

Права администратора требуются для выполнения следующих операций удаленного взаимодействия:— Установление удаленного подключения к локальному компьютеру. Такое подключение называется «loopback» или «local» сессия.— Настройка конфигурации сессии на локальном компьютере.— Просмотр и изменение настроек WS-Management на локальном компьютере. Эти настройки находятся в узле LocalHost на диске WSMAN:.

Для выполнения этих задач, пользователь должен запустить Windows PowerShell с параметром «Запуск от имени администратора», даже если он является членом группы администраторов на локальном компьютере.

В Windows 7 и Windows Server 2008 R2, чтобы запустить Windows PowerShell с параметром «Запуск от имени администратора»:1. Нажмите кнопку Пуск, выберите «Все программы», войдите в «Стандартные», а затем нажмите на папку «Windows PowerShell».2. Щелкните правой кнопкой мыши на ярлык «Windows PowerShell», а затем нажмите кнопку «Запуск от имени администратора».

В ранних версиях Windows, чтобы запустить Windows PowerShell с параметром «Запуск от имени администратора»:1. Нажмите кнопку «Пуск», выберите «Все программы», а затем зайдите папку «Windows PowerShell».2. Щелкните правой кнопкой мыши на ярлык «Windows PowerShell», а затем нажмите кнопку «Запуск от имени администратора».

В проводнике Windows опция «Запуск от имени администратора», также доступна в других видах запуска Windows PowerShell, в том числе на ярлыках. Просто нажмите правой кнопкой мыши элемент, а затем нажмите кнопку «Запуск от имени администратора».

Когда вы запускете Windows PowerShell из другой программы, такой как Cmd.exe, используйте опцию «Run as administrator» при запуске программы.

Как настроить компьютер для удаленного доступа

Компьютеры под управлением всех поддерживаемых версий Windows, могут устанавливать удаленные подключения и выполнять удаленные команды в Windows PowerShell без предварительной конфигурации. Тем не менее, для получения соединения, и разрешения пользователям создавать локальные или удаленные сессии управления с помощь Windows PowerShell («сессии PSSession») и выполнять команды на локальном компьютере, необходимо включить удаленное взаимодействие Windows PowerShell на компьютере.

В Windows Server 2012 и более новых выпусках Windows Server удалённое взаимодействие включено в Windows PowerShell по умолчанию. Если настройки были изменены, можно восстановить настройки по умолчанию, выполнив командлет Enable-PSRemoting.

На всех других поддерживаемых версиях Windows, необходимо запустить командлет Enable-PSRemoting, чтобы включить удаленное взаимодействие Windows PowerShell.

Удаленное взаимодействия Windows PowerShell поддерживаются службой WinRM, которая является реализацией Microsoft протокола управления веб-службами(WS-Management). При включении удаленного взаимодействия Windows PowerShell, изменяется конфигурация по умолчанию WS-Management и добавляется конфигурация системы, которая позволит пользователям подключаться к WS-Management.

Чтобы настроить Windows PowerShell для получения удаленных команд:1. Запустите Windows PowerShell с параметром «Запуск от имени администратора».2. В командной строке введите:

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

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

C:\PS> new-pssession Id Name ComputerName State ConfigurationName -- ---- ------------ ----- ----- 1 Session1 localhost Opened Microsoft.PowerShell

C:\PS> new-pssession

Id Name ComputerName State ConfigurationName

-- ---- ------------ ----- -----

1 Session1 localhost Opened Microsoft.PowerShell

Если команда не сработала, рекомендуется прочитать, about_Remote_Troubleshooting.

Определение политики

Когда вы работаете удаленно, используется два экземпляра Windows PowerShell, один на локальном компьютере и один на удаленном компьютере. В результате, ваша работа зависит от политики Windows и политики Windows PowerShell, на локальных и удаленных компьютерах.

Перед тем как установить соединение действует политика локального компьютера. Когда произошло соединение действует политика на удалённом компьютере.

coolcode.ru

PowerShell. О отложенных сессиях (about_Remote_Disconnected_Session) — Клёвый код

Командлеты отложенных сессий

Как работает функция отложенных сессий

Как получить объект PSSession.

Как отключиться от сессии

Как подключиться к отложенной сессии

Как получить результаты

Состояние и доступность

Время простоя

ЗАМЕТКИ:

Режим работы буфера вывода

Допустимые значения:

Локальные отложенные сессии

Ожидание заданий в отложенных сессиях

Надёжность сессий и непреднамеренное разъединение

Управление настройками сети с помощью PowerShell

Вариантов несколько, самый древний и известный это использование netsh:

Второй способ, это sconfig , он прост и понятен:

Теперь посмотрим как настроить сетевое подключение с помощью PowerShell:

Related

Дистанционное взаимодействие в среде PowerShell 2.0 | Windows IT Pro/RE

Где можно получить Windows PowerShell 2.0

Включение функции удаленного взаимодействия

Выполнение одной команды на удаленном компьютере

Выполнение блока сценария (Scriptblock) на удаленном компьютере

Выполнение блока сценария на нескольких удаленных компьютерах

Выполнение блока сценария в фоновом режиме

Создание сеансов PowerShell

Новый подход к работе

Создание удаленных сессий в PowerShell 2.0 | Windows IT Pro/RE

Основы удаленного взаимодействия в PowerShell

Обзор WinRM

Удаленное взаимодействие 1:1

Удаленное взаимодействие 1:n

Есть кое-что еще!

Подключение к клиентам Exchange Online с помощью удаленного сеанса Windows PowerShell для партнеров службы разрешений делегированного доступа (DAP)

In this article

Что нужно знать перед началом работыWhat do you need to know before you begin?

Подключение к Exchange Online для организаций пользователейConnect to Exchange Online for customer organizations

Как проверить, что все получилось?How do you know this worked?

Вызов командлета напрямую с помощью команды Invoke-CommandCall the cmdlet directly with Invoke-Command

Дополнительные командлеты для отчетовMore reporting cmdlets

Включение подключения к удаленному рабочему столу для роли в облачных службах Azure с помощью PowerShell

In this article

Настройка удаленного рабочего стола с помощью PowerShellConfigure Remote Desktop from PowerShell

Подключение к экземпляру роли по протоколу удаленного рабочего столаRemote Desktop into a role instance

Убедитесь, что расширение удаленного рабочего стола включено в службе.Check if Remote Desktop extension is enabled on a service

Удаление расширения удаленного рабочего стола из службыRemove Remote Desktop extension from a service

Дополнительные ресурсыAdditional resources

PowerShell. О требованиях к инраструктуре для работы дистанционного подключения. (about_Remote_Requirements) — Клёвый код

Системные требования

Права пользователя

Сетевое окружение Windows

Запуск от имени администратора

Как настроить компьютер для удаленного доступа

Определение политики