Командлет Enter-PSSession позволяет создать постоянную интерактивную PowerShell сессию с удаленным компьютером. Все команды, которые вы вводите в вашей командной строке, выполняются на удаленном компьютере. В этой статье мы рассмотрим основные возможности и особенности использования командлета Enter-PSSession для удаленного управления компьютерами с Windows 10 и Windows Server 2019/2016.
Командлет Enter-PSSession работает на базе стека PowerShell Remoting. PSRemoting основан на Web Services for Management (WS-Management). Для связи используется служба WinRM (Windows Remote Management). Трафик между компьютерами шифруется на уровне протокола (можно использовать SSL шифрование). Для аутентификации можно использовать различные методы, в том числе NTLM и Kerberos.
Для подключения в самом простом случае нужно указать только имя компьютера (параметр ComputerName). Чтобы подключиться к удаленному компьютеру, достаточно выполнить команду:
Enter-PSSession hq-srv01.contoso.com
Если у текущего пользователя есть полномочия на подключение к удаленному серверу, вы подключитесь к удаленному компьютеру.
Можно перед подключением запросить учетные записи пользователя:
Enter-PsSession –ComputerName hq-srv01.contoso.com –Credentials contoso\kbuldogov
Или так:
$creds = Get-Credential
Enter-PSSession -ComputerName hq-srv01 -Credential $creds
Обратите внимание, что в начале командной строки PowerShell теперь в квадратных скобках указывается имя удаленного компьютера (
[hq-srv01.contoso.com]
). Это позволяет понять, работаете ли вы в локальной сессии или в удаленной.
В вашей консоли отображаются результаты всех команд, выполненных удаленно. Можно выполнить команду hostname и убедится, что вы выполнили команду на удаленном компьютере.
В этой интерактивной командной строке вы можете выполнять любые команды (в соответствии со своими полномочиями).
Например, выведем настройки сети:
Get-NetIPConfiguration
Можно изменить настройки DNS на удаленном компьютере:
Set-DNSClientServerAddress –InterfaceIndex 6 –ServerAddresses 192.168.13.4, 192.168.100.4
Чтобы завершить интерактивную сессию удаленного управления, нужно выполнить команду Exit-PSSession или exit. Строка-приглашение PS примет свой обычный вид, и вы вернетесь к своей локальной PowerShell консоли:
Ранее для запуска интерактивной командной строки с удаленным Windows компьютером администраторы в основном использовалась утилиту PsExec. Но с появлением Enter-PSSession необходимость в использовании сторонней утилиты исчезла.
В Windows Server 2016/2019 PowerShell Remoting включен по умолчанию (это видно в консоли Server Manager -> Local Server -> Remote Management = Enabled).
В десктопных версиях Windows (Win10, Win11) PSRemoting и служба WinRM отключены.
Вы можете проверить, включен ли PSremoting на текущем компьютере:
Get-PSSessionConfiguration
Данная команда также позволяет получить список пользователей и групп, которым разрешено подключаться через WinRM. Для использования PSRemoting учетная запись пользователя должна состоять в группе
Administrators
или
Remote Management Users
. Особенности удаленного использования WinRM без прав администратора описаны здесь.
Вы можете протестировать, можно ли подключится через PowerShell Remoting к вашему компьютеру локально:
Test-WSMan -ComputerName localhost
Если команда вернет версию схемы WSMan, значит удаленные подключения к этому компьютеру через PS Remoting разрешены.
Если PowerShell Remoting отключен или не настроен, появился ошибка:
Test-WSMan : <f:WSManFaultxmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150858770" Machine="srv02"><f:Message>The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
Чтобы включить PowerShell Remoting, выполните команду:
Enable-PSRemoting -Force
Данная команда:
- Включает службу WinRM и настраивает ее на автозапуск;
- Создает точку подключения на стандартном порту WinRM (TCP/5985 для HTTP трафика);
- Добавляет исключения в Windows Firewall для WS-Management (если вы настраиваете PSRemoting вручную, добавьте правило самостоятельно);
- Разрешает удаленные PowerShell сессии;
- Перезапускает службу WinRM.
Убедитесь, что служба WinRM запущена и настроена на автоматический запуск:
Get-Service WinRM | Select MachineName,Name,Status, StartType
Команда Enable-PSRemoting работает только для доменного и частного сетевых профилей Windows. Если вы хотите включить PSRemoting на компьютере в общей (public) сети, нужно изменить тип сети на частную или воспользоваться командой:
Enable-PSRemoting -SkipNetworkProfileCheck -Force
В домене Active Directory проще всего настроить Windows Remote Management (PSRemoting) на серверах и компьютера централизованно с помощью групповой политики.
В новых версиях PowerShell(v6 и v7) поддерживается использование протокола Secure Shell (SSH) для подключения к удаленному компьютеру через PowerShell Remoting. На удаленном компьютере должен быть доступна точка подключения SSH (в Windows теперь есть встроенный SSH сервер). Вы можете запустить интерактивную сессию PSRemoting поверх SSH с помощью команды:
Enter-PSSession -HostName [email protected]
Или аутентифицироваться по SSH с помощью RSA ключа:
Enter-PSSession -HostName [email protected]:22 -KeyFilePath c:\PS\your_rsa_key
Enter-PSSession можно использовать совместно с командой New-PSSession:
$s = New-PSSession -ComputerName hq-srv01.contoso.com
Enter-PSSession -Session $s
Enter-PSSession поддерживает несколько способов аутентификации. Вы можете задать нужный способ с помощью параметра
-Authentication
. Поддерживаются Basic, Digest, Kerberos, CredSSP, NegotiateWithImplicitCredential, Negotiate Challenge.
В примере выше мы показали пример интерактивного подключения Enter-PSSession между компьютерами в одном домене Windows (для подключения достаточно указать FQDN или короткое имя, используется Kerberos аутентфикация). Если попробовать подключиться к удаленному компьютеру по IP адресу или CNAME, аутентификация не пройдет:
Enter-PSSession : Connecting to remote server 192.168.13.5 failed with the following error message: The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated.
Для подключения к удаленному компьютеру по IP можно добавить этот хост в список доверенных (Trusted Hosts) или использовать SSL (более безопасно).
Чтобы добавить IP адрес в доверенные, выполните команду:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 192.168.13.5
Можно добавить в доверенные хосты по маске
Set-Item WSMan:\localhost\Client\TrustedHosts -Value *.winitpro.ru
Вывести список доверенных хостов:
Get-Item WSMan:\localhost\Client\TrustedHosts
Аналогично нужно добавить ваш хост в доверенные на удаленном компьютере.
Перезапустите службу:
Restart-Service WinRM
Чтобы подключиться к удаленному компьютеру по IP адресу, используйте такую команду:
Enter-PSSession -ComputerName 192.168.13.5 -Credential (Get-Credential -UserName contoso\kbuldogov)
Командлеты Enter-PSSession и New-PSSession создают постоянную сессию типа один к одному и используются в основном в интерактивных сценариях. Если вам нужно автоматизация, или есть задачи, которые нужно выполнить сразу на множестве удаленных компьютерах, используйте командлет Invoke-Command.
В предыдущих статьях мы разобрались с основами среды и достаточно подробно изучили язык программирования Microsoft PowerShell. Завершая цикл, мы рассмотрим работу с процессами и службами, реестром и журналами событий в распределенной среде, а также разберем некоторые способы администрирования операционной системы, настройки стороннего ПО и просмотра сведений об установленном оборудовании. Для этого в PowerShell активно применяются объекты различных типов, изучению которых были посвящены четвертая и пятая части цикла.
Оглавление:
Удаленное управление
Командлеты vs CIM/WMI
Управление процессами через CIM/WMI
Управление службами через CIM/WMI
Работа с реестром
Работа с журналами событий
Информация об ОС и оборудовании
Удаленное управление
PowerShell позволяет удаленно управлять одним или несколькими компьютерами. Для этого можно задействовать объекты .NET, CIM, WMI, поддерживающие соответствующую функцию командлеты, удаленный запуск команд или интерактивную удаленную сессию. Подключение осуществляется через PS remoting/WinRM по протоколу HTTP (порт 5985) или HTTPS (порт 5986, требуется сертификат SSL). По умолчанию соединение устанавливается по HTTP, но данные все равно шифруются с использованием симметричного ключа AES-256. Поддерживаются два способа аутентификации: NTLM и Kerberos (по умолчанию). Второй способ доступен, если удаленный компьютер входит в домен AD, а в Workgroup или если вместо доменного имени указан IP, применяется NTLM и требуется дополнительная настройка. На компьютере, к которому мы подключаемся, должен быть запущен сервис WinRM.
Если сервис не запущен, можно воспользоваться командлетом Enable-PSRemoting. Виртуальные машины RuVDS с Windows Server Core конфигурируются с настроенным из коробки удаленным доступом и никаких дополнительных действий не требуют. Для использования HTTP также придется добавить хост, к которому необходимо подключиться, в TrustedHost компьютера, с которого запускается команда. Если машина работает в глобальной сети, может потребоваться настройка брендмауэра. PS remoting/WinRM позволяет создавать удаленные сессии (New-PSSession, Get-PSSession, Enter-PSSession), выполнять команды и скрипты (Invoke-Command) на одном или нескольких компьютерах, а также использовать командлеты с параметром -ComputerName. Последнее справедливо и в отношении командлетов для работы с CIM/WMI. Более подробная информация доступна на сайте Microsoft.
Командлеты vs CIM/WMI
Хотя некоторые командлеты поддерживают параметр -ComputerName, возможности их применения для работы с хостами в сети ограничены. Создания сессий и удаленного выполнения команд PowerShell хватает не всегда, и тут нам помогут командлеты для работы с WMI или CIM (иногда можно обойтись и NET-объектами). Использование CIM предпочтительнее, поскольку дальнейшая разработка и поддержка WMI в Windows прекращена. В обоих случаях используется Common Information Model (CIM) и экземпляры соответствующих классов. При необходимости можно просматривать структуру результирующих объектов, фильтровать, сортировать и выделять их из коллекции, а также проводить другие действия над полученными результатами. При работе в интерактивном режиме текстовый вывод несложно отформатировать, а в скриптах обычно обращаются к свойствам и методам объектов. Хотя командлеты WMI и CIM похожи, в первом случае нетрудно получить ссылку на конкретный объект (экземпляр класса) и непосредственно вызвать один из его методов без использования Invoke-WmiMethod. Результирующие CIM-объекты методов класса не содержат, поэтому вызывать командлет Invoke-CimMethod для управления придется обязательно.
Управление процессами через CIM/WMI
В предыдущих статьях мы довольно часто использовали Get-Process, который возвращает соответствующие запущенным в системе процессам объекты типа System.Diagnostics.Process. С помощью этого командлета можно получать сведения только о локальном компьютере, а чтобы работать с удаленной машиной, нам снова понадобятся командлеты CIM/WMI и класс Win32_Process. Приведем примеры используемых для работы с ним команд.
Get-WmiObject Win32_Processили
Get-CimInstance Win32_Process
Предыдущие примеры иллюстрируют получение информации о запущенных на локальной машине процессах, для работы с удаленными компьютерами используется параметр -ComputerName:
Get-WmiObject Win32_Process -ComputerName IP_ADDRESS
Get-WmiObject Win32_Process -ComputerName NAMEили
Get-CimInstance Win32_Process -ComputerName IP_ADDRESS
Get-CimInstance Win32_Process -ComputerName NAMEУправление службами через CIM/WMI
Командлет Get-Service в актуальных реализациях поддерживает параметр -ComputerName, но позволяет только получить информацию о статусе сервиса на удаленной машине — управлять им через свойства и методы результирующих объектов не получится. Более правильным в распределенной среде подходом также считается использование командлетов CIM и WMI. Как и для процессов, для служб в объектной модели CIM имеется специальный класс Win32_Service.
Get-WmiObject Win32_Serviceили
Get-CimInstance Win32_service
Чтобы работать с удаленным компьютером, необходимо воспользоваться параметром -ComputerName:
Get-WmiObject Win32_Service -ComputerName IP_ADDRESS
Get-WmiObject Win32_Service -ComputerName NAMEили
Get-CimInstance Win32_service -ComputerName IP_ADDRESS
Get-CimInstance Win32_service -ComputerName NAMEДля уточняющих запросов используется параметр -Filter. Таким способом несложно выяснить, стартует служба автоматически или должна быть запущена вручную:
Get-Wmiobject Win32_service -Filter "StartMode <>'disabled'" | sort StartMode | format-table -GroupBy StartMode -Property Name,State,PathName -AutoSizeАналогичным образом можно сгруппировать службы по учетной записи:
Get-Wmiobject Win32_service | group startnameСледующая команда возвращает все сервисы, запущенные от имени администратора:
Get-Wmiobject Win32_service -Filter "startname like '%administrator%'" | Select Name,startmode,state,startname,systemnameДля командлетов CIM фильтры работают аналогично:
Get-CimInstance Win32_service -filter "startmode='auto' AND state<>'Running'" | Select Name,State,SystemnameДля реальной работы важен не столько текстовый вывод командлетов, сколько сами бинарные объекты. С их помощью можно запускать и останавливать соответствующие службы, менять режим их запуска или устанавливать свойства. В случае с WMI методы объектов вызываются напрямую или через Invoke-WmiMethod. Для объектов CIM доступно только использование Invoke-CimMethod.
Работа с реестром
Системный реестр Windows — это имеющая древовидную структуру иерархическая база данных, содержащая информацию об аппаратной и программной конфигурации компьютера. Каждый ее узел — это содержащий другие узлы (записи базы данных) раздел либо имеющий некое значение ключ. Раздел может содержать вложенные подразделы: по структуре реестр напоминает файловую систему и для работы с ним в PowerShell есть виртуальные «диски». Просмотреть их можно с помощью командлета Get-PSDrive, а обратиться к соответствующему разделу — с помощью Set-Location (псевдоним cd).
«Диски» реестра содержат «каталоги» (разделы), подкаталоги «подразделы» и «файлы» (параметры). Для просмотра подразделов используется командлет Get-ChildItem (псевдоним dir), а для просмотра параметров: Get-ItemProperty. Разделы реестра представлены экземплярами .NET-класса Microsoft.Win32.RegistryKey, а параметры — System.Management.Automation.PSCustomObject. Чтобы получить доступ к системному реестру удаленной машины, придется напрямую использовать объекты .NET, WMI или CIM.
Работа с журналами событий
Журналы событий (Event logs) в Windows — важный для администратора инструмент, с помощью которого можно отслеживать состояние системы и приложений, а также оперативно анализировать возникающие проблемы. Обычно для работы нужны журнал безопасности (Security log), системный журнал (System log) и журнал приложений (Application log). В зависимости от установленных компонентов и настроенных ролей, на сервере могут быть и другие: журнал службы каталога (Directory service log), журнал службы каталога (Directory service log) или, например, журнал службы репликации файлов (File Replication Service log). Для их просмотра на локальной машине используется консоль управления MMC, а в PowerShell командлет Get-EventLog. Для работы с удаленными хостами можно воспользоваться соответствующими определенным журналам объектами CIM и WMI (экземплярами класса Win32_NTEventlogFile).
$Logs = Get-WmiObject Win32_NTEventlogFile
$Logs | Format-Listили
$Logs = Get-CimInstance Win32_NTEventlogFile
$Logs | Format-List
Пример иллюстрирует работу с локальными журналами, для подключения к удаленному компьютеру нужен параметр -ComputerName:
$Logs = Get-WmiObject Win32_NTEventlogFile -ComputerName NAME
$Logs | Format-Listили
$Logs = Get-CimInstance Win32_NTEventlogFile -ComputerName NAME
$Logs | Format-ListИнформация об ОС и оборудовании
С помощью командлетов CIM и WMI можно получать разнообразную информацию от работающих в сети компьютеров, а также управлять ими. Для этих целей применяются командлеты CIM/WMI и соответствующие классы. Рассмотрим их использование на практических примерах.
Класс Win32_OperatingSystem решает множество разнообразных задач. С помощью его метода Win32Shutdown завершается сеанс пользователя:
(Get-WMIObject Win32_OperatingSystem).Reboot()Для получения информации о BIOS потребуется класс Win32_BIOS
Get-WmiObject Win32_BIOS | Select-Object -Property * -ExcludeProperty __*или
Get-CimInstance Win32_BIOS | Select-Object -Property * -ExcludeProperty __*
Вывод свойств операционной системы:
Get-WmiObject Win32_OperatingSystem | Select-Object –Property * -ExcludeProperty __*или
Get-CimInstance Win32_OperatingSystem | Select-Object –Property * -ExcludeProperty __*
Класс Win32_QuickFixEngineering предназначен для получения списка установленных обновлений:
Get-WmiObject Win32_QuickFixEngineeringили
Get-CimInstance Win32_QuickFixEngineeringЗавершая цикл публикаций, мы хотим напомнить, что PowerShell — нечто большее, чем просто командная оболочка. Скорее она напоминает гибрид Bash и SSH/SSHD с возможностью использования объектов .NET и объектной модели CIM. Это позволяет решать сложные задачи управления распределенной ИТ-средой, хотя и требует иногда громоздких синтаксических конструкций. Без знания PowerShell сегодня не обойдется ни один грамотный системный администратор Windows.
Часть 1: Основные возможности Windows PowerShell
Часть 2: Введение в язык программирования Windows PowerShell
Часть 3: Передача параметров в скрипты и функции, создание командлетов
Часть 4: Работа с объектами, собственные классы
Часть 5: Доступ к внешним объектам
To connect to a remote computer using PowerShell, you can utilize the `Enter-PSSession` cmdlet, which allows you to create a session on a remote machine. Here’s a code snippet to illustrate this:
Enter-PSSession -ComputerName 'RemoteComputerName' -Credential (Get-Credential)
Understanding Remote Connections in PowerShell
What are Remote Connections?
Remote connections allow users to access and manage resources on another computer over a network. With the increasing demand for remote management, understanding how to effectively connect to remote machines is essential for system administrators and IT professionals. Common scenarios include system diagnostics, software installations, and routine maintenance tasks, all of which can be executed efficiently through remote connections.
Why Use PowerShell for Remote Connections?
PowerShell offers a powerful command-line environment designed for system administration and automation. Its remoting capabilities are built-in, providing users with secure and efficient methods for managing multiple systems from a single interface. Compared to other methods (like Remote Desktop Protocol), PowerShell allows for bulk operations, scripting, and task automation, making it invaluable for managing enterprise environments.
PowerShell Connect to Remote Computer and Run Command Guide
Prerequisites for Connecting to a Remote Computer
Network Requirements
To establish a successful connection to a remote computer, ensure that both the local and remote machines are connected to the same network or linked via Virtual Private Network (VPN). A faulty network setup can hinder the connection process, making it essential to verify that the machines can communicate over the network.
PowerShell Remoting Setup
Before using PowerShell to connect to a remote computer, you must ensure that PowerShell Remoting is enabled on the remote machine. This can be done using the following command:
Enable-PSRemoting -Force
This command configures the necessary settings automatically, allowing PowerShell to accept remote commands.
Firewall Configuration
If the remote connection is still unsuccessful after enabling remoting, it’s crucial to examine the firewall settings on the remote machine. Firewalls may block PowerShell remoting traffic, preventing connection attempts. You can check whether the Windows Firewall permits PowerShell remoting with the following command:
Get-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)"
If it’s not enabled, adjustments will need to be made to allow the traffic.
PowerShell to Copy Files to Remote Computers Made Easy
Connecting to a Remote Computer Using PowerShell
Basic Command Structure
To connect to a remote machine using PowerShell, you typically use the `Enter-PSSession` or `Invoke-Command` cmdlets. The fundamental syntax for the `Enter-PSSession` command looks like this:
Enter-PSSession -ComputerName "RemotePC" -Credential (Get-Credential)
This command alerts PowerShell to initiate a remote session to the specified computer, using the provided credentials for authentication.
Exploring `Enter-PSSession`
The `Enter-PSSession` command allows you to work interactively with a remote machine. Upon successful execution, you will see the prompt change to indicate that you are now in a remote session. An example of this command is:
Enter-PSSession -ComputerName "RemotePC" -Credential "DOMAIN\User"
Here, replace `»RemotePC»` with the actual name or IP address of the target machine and provide valid credentials.
Using `Invoke-Command` for Multiple Commands
If you need to run multiple commands without entering an interactive session, `Invoke-Command` is the ideal choice. This cmdlet enables batch commands whereas still maintaining a connection to the remote system. Here’s how you could use it to retrieve the list of running processes on the remote computer:
Invoke-Command -ComputerName "RemotePC" -ScriptBlock { Get-Process }
The `-ScriptBlock` parameter allows you to specify the commands that should be executed on the remote system.
PowerShell Shutdown Remote Computer: A Quick Guide
Managing Remote Sessions
Viewing Active Remote Sessions
To view active sessions and manage them, the `Get-PSSession` cmdlet is quite useful:
Get-PSSession
This command displays all current sessions, allowing you to monitor and manage your connections.
Closing Remote Sessions
When you’re finished working on a remote machine, it is essential to terminate the session correctly with the `Exit-PSSession` command:
Exit-PSSession
This command will ensure all resources are freed, and you return to your local PowerShell prompt seamlessly.
Mastering PowerShell Connect-AzAccount in Minutes
Troubleshooting Common Connection Issues
Common Errors and Their Solutions
Encountering errors while trying to connect to a remote machine is not uncommon. For instance, if you see «Access Denied,» it usually indicates issues with credentials or insufficient permissions on the remote machine. Ensure that you are using the correct user account that has remote access privileges.
Similarly, if you receive a «Network Path Not Found» error, check that the target machine is powered on and reachable over the network. Consult network configurations and ensure both computers are correctly configured within the same network or accessible through VPN.
Testing Connectivity
Before diving into extensive troubleshooting, you can verify that the target machine is reachable by using the following command:
Test-WSMan -ComputerName "RemotePC"
This command tests the availability of the Windows Remote Management service on the specified remote machine.
PowerShell: Stop Service on Remote Computer Made Easy
Security Considerations
Using Secure Connections
To maintain secure connections, it is crucial to use encrypted channels when performing remote operations. PowerShell Remoting utilizes HTTPS connections when configured accordingly. Implementing SSL can significantly enhance security, especially in corporate environments handling sensitive data.
Limiting Access to Specific Users
To reinforce security further, it’s essential to limit remote access to authorized users only. Consider creating dedicated groups specifically for PowerShell remoting purposes. This can help you control who can access and execute commands on remote systems effectively.
PowerShell Connect to MSSQL: A Simple Guide
Conclusion
Connecting to a remote computer using PowerShell can dramatically enhance productivity and system management efficiency. Understanding the prerequisites for setting up remote connections, mastering the basic command structures, and being aware of troubleshooting steps are key components of successful remote management.
With continuing practice, users can harness the full potential of PowerShell remoting, paving the way for streamlined operations and increased productivity in IT environments. Engage with the PowerShell community and explore further resources to build on the foundational knowledge presented in this guide.
Table of Contents
PowerShell Remoting uses the WS-Management protocol and lets you run any PowerShell command on one or more remote computers. It lets you establish persistent connections, start interactive sessions, and run scripts on multiple computers.
To use PowerShell remoting, remote computer must be configured for remote management. But there are many PowerShell cmdlets with a ComputerName parameter that enables you to collect data and change settings on one or more remote computers without any configuration on remote computer. They use a variety of communication technologies and many work on all Windows operating systems that Windows PowerShell supports without any special configuration.
The cmdlets which does not require any configuration on remote machine are:
- Restart-Computer
- Test-Connection
- Clear-EventLog
- Get-EventLog
- Get-Hotfix
- Get-Process
- Get-Service
- Set-Service
- Get-WinEvent
- Get-WmiObject
All of cmdlets shown above does not use WS-Management protocol. These cmdlets use Microsoft .NET Framework methods to retrieve the objects from remote computers and does not use PowerShell remoting infrastructure. So, these cmdlets can be run on remote computers without the need to any configuration on remote computers.
Typically, the cmdlets which support remoting without special configuration have a ComputerName parameter and do not have a Session parameter. To find these cmdlets, you can use the following command:
PS D:\MyScripts> Get-Command | Where-Object {$_.parameters.keys -contains "ComputerName" -and $_.parameters.keys -notcontains "Sessi on" -and $_.ModuleName -notlike "*WSMan*"} CommandType Name ModuleName ----------- ---- ---------- Cmdlet Add-Computer Microsoft.PowerShell.Management Cmdlet Clear-EventLog Microsoft.PowerShell.Management Cmdlet Get-EventLog Microsoft.PowerShell.Management Cmdlet Get-HotFix Microsoft.PowerShell.Management Cmdlet Get-Process Microsoft.PowerShell.Management Cmdlet Get-PSSession Microsoft.PowerShell.Core [output cut]
Requirements for PowerShell Remoting
To use PowerShell remoting infrastructure, the local and remote computers must have:
- Windows PowerShell 2.0 or later
- The Microsoft .NET Framework 2.0 or later
- Windows Remote Management 2.0
To find the version number of an installed version of Windows PowerShell, you can use the $PSVersionTable automatic variable. The value of the $PSVersionTable.Version.Major property must be at least 2.
Windows Remote Management 2.0 is included in Windows 7 and in Windows Server 2008 R2. It is also included in the integrated installation package for earlier versions of Windows that includes PowerShell. PowerShell Integrated Scripting Environment (ISE) and the Out-Gridview cmdlet require the Microsoft .NET Framework 3.5 with Service Pack 1. The Get-WinEvent cmdlet requires the Microsoft .NET Framework 3.5 or greater. These upgrades are not required for remoting.
Configure PowerShell Remoting
The remoting features of Windows PowerShell are supported by the WinRM service, which is the Microsoft implementation of the Web Services for Management (WS-Magement) protocol. To use the remoting features, you need to change the default configuration of WS-Management on the system.
To configure Windows PowerShell to receive remote commands:
1. Start Windows PowerShell. In Windows Vista and later versions of Windows, start Windows PowerShell with the “Run as administrator” option.
2. At the command prompt, use Enable-PSRemoting –Force command:
PS C:\Windows\system32> Enable-PSRemoting -Force WinRM has been updated to receive requests. WinRM service type changed successfully. WinRM service started.
If you run Enable-PSRemoting command without -Force, you will have to confirm the Y/N prompt two times as shown below:
This procedure allows users on other computers to establish remote connections and to run remote commands on the local computer. It also allows you to create a “loopback” connection on the local computer.
The same can be done using Windows cmd.exe (command prompt).
C:\Windows\system32>winrm quickconfig -quiet WinRM service is already running on this machine. WinRM is already set up for remote management on this computer.
PowerShell remoting is primarily intended for remotely managing domain-joined computers, and if you are preparing to deploy the first domain controller in a new forest there is no domain to join yet. In other words, the PC on which you are working is in workgroup and the remote server that you want to promote to a domain controller is also in a workgroup, not a domain. If you try to run any command on remote server, you will get the error as shown below:
PS C:\> Get-WindowsFeature -ComputerName DC2 Get-WindowsFeature : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer DC2. Verify that the computer exists on the network and that the name provided is spelled correctly. At line:1 char:1 + Get-WindowsFeature -ComputerName DC2 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : DeviceError: (Microsoft.Manag...rDetailsHandle):CimException) [Get-WindowsFeature], Exception + FullyQualifiedErrorId : UnSupportedTargetDevice,Microsoft.Windows.ServerManager.Commands.GetWindowsFeatureCommand
The error message clearly states that Error occurred while using Kerberos authentication. This is because by default WS-Man protocol uses Kerberos authentication. Since all computers are yet in workgroup environment; the Kerberos is not supported.
You need to enable the two stand-alone computers to talk to each other using the WS-Management protocol. If the computer from which you are running the remote commands is also running Windows Server 2012 or Windows Server 2012 R2, you just need to add the name of the remote server to the TrustedHosts list in the local computer’s WinRM configuration. Doing this enables the local computer to connect to the remote server using NTLM as the authentication mechanism instead of Kerberos, which is used in domain-based environments.
By default, the TrustedHosts list is empty on every computer. So, it does not allow commands to any remote computer which is not in domain.
PS C:\> Get-Item WSMan:\\localhost\client\TrustedHosts WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client Type Name SourceOfValue Value ---- ---- ------------- ----- System.String TrustedHosts
Now, you need to add remote ComputerName to TrsutedHosts list using Set-Item cmdlet as shown below:
PS C:\> Set-Item WSMan:\\localhost\client\TrustedHosts -Value DC2 -Concatenate -Force
That the –Concatenate parameter is mandatory if you want to add multiple conputers, otherwise every time you run the Set-Item command, it will keep overwriting the old values in TrustedHosts list. The -Force parameter is however optional, which is used to suppress the confirmation (Yes/No) prompt. Now, take a look on TrustedHosts list again.
PS C:\> Get-Item WSMan:\\localhost\client\TrustedHosts WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client Type Name SourceOfValue Value ---- ---- ------------- ----- System.String TrustedHosts DC2
The DC2 is now listed under TrsustedHosts. You can now run PowerShell remoting commands on this remote computer from local computer.
If you are already in domain environment, you do not need to mess-up with TrustedHosts.
Starting Interactive Remote Session
To start an interactive session with a single remote computer, you can use the Enter-PSSession cmdlet. For example, to start an interactive session with the DC1 remote server, type:
PS D:\MyScripts> Enter-PSSession -ComputerName DC1
[DC1]: PS C:\Users\surender\Documents>
The above command will start an interactive session with remote computer with currently logged-on user credentials. The command prompt changes to display the name of the computer to which you are connected. From then on, any commands that you type at the prompt run on the remote computer and the results are displayed on the local computer. Lets take a look at the syntax and other available optional parameters of Enter-PSSession command.
PS D:\MyScripts> Get-Help Enter-PSSession NAME Enter-PSSession SYNOPSIS Starts an interactive session with a remote computer. SYNTAX Enter-PSSession [-ComputerName] <String> [-ApplicationName <String>] [-Authentication <AuthenticationMechanism>] [-CertificateThumbprint <String>] [-ConfigurationName <String>] [-Credential <PSCredential>] [-EnableNetworkAccess] [-Port <Int32>] [-SessionOption <PSSessionOption>] [-UseSSL] [<CommonParameters>
Notice that Enter-PSSession cmdlet has a –Credential parameter which you can use to use to provide alternate credentials while connecting to remote computer. To use this parameter, run the command as shown below:
You will see a dialog box prompting for credentials to be used to connect to remote computer.
To end the interactive session, type Exit-PSSession or simply exit command.
[DC1]: PS C:\Users\surender\Documents> Exit-PSSession
PS D:\MyScripts>
Run a Remote Command
You do not always want to start interactive session to remote computer. What if you want to run just a single command on remote computer? PowerShell has Invoke-Command cmdlet to do this. To run any command on one or many remote computers, use the Invoke-Command cmdlet as shown below:
PS D:\MyScripts> Invoke-Command -ComputerName DC1, DC2, FileServer, LocalHost -ScriptBlock {Get-WmiObject -Class Win32_OperatingSystem | Format-List PSComputerName, Caption}
Caption PSComputerName RunspaceId
------- -------------- ----------
Microsoft Windows Server 2008 R2 Standard DC1 4a372458-5ca8-4d64-9e1c-66d2acd40800
Microsoft Windows 8.1 Enterprise LocalHost 3a819c2f-17af-47e4-adf3-f5736d1568c4
Microsoft Windows Server 2008 R2 Standard DC2 263a7f27-b1e2-40f2-acd2-6d6e9af8a972
Microsoft Windows Server 2012 R2 Standard FileServer ed664ed8-39f2-448b-99fc-fc8778ede30e
To run a script on one or more remote computers, use the –FilePath parameter of the Invoke-Command cmdlet. The script must be on or accessible to your local computer. The results are returned to your local computer.
For example, the following command runs the Get-DiskUsage.ps1 script on the DC1 and DC2 servers.
PS D:\MyScripts> Invoke-Command -ComputerName DC1, DC2 -FilePath D:\MyScripts\Get-DiskUsage.ps1
Name Used (GB) Free (GB) Provider Root CurrentLocation PSComputerName
---- --------- --------- -------- ---- --------------- --------------
C 42.06 37.45 C:\ ...surender\Documents DC1
D 191.68 193.95 D:\ DC1
E E:\ DC1
F 578.04 352.95 F:\ DC1
C 57.35 240.64 C:\ ...surender\Documents DC2
D 550.36 381.15 D:\ DC2
PowerShell remote management just begins here. By using the cmdlets installed with PowerShell, you can establish and configure remote sessions both from the local and remote ends, create customized and restricted sessions, allow users to import commands from a remote session that actually run implicitly on the remote session, configure the security of a remote session, and much more.
Back
Чтобы обеспечить возможность удаленного взаимодействия с помощью PowerShell, необходимо произвести некоторые настройки. Количество этих настроек зависит от операционной системы, сетевого окружения, требований к безопасности (и еще бог знает чего). Поскольку настроек довольно много, я попробую рассказать о наиболее важных из них. Ну, поехали…
Включение удаленного управления
Для того, чтобы управлять удаленным компьютером, необходимо на этом компьютере удаленное взаимодействие разрешить. Исключение составляет Windows Server 2012, где все возможности удаленного управления включены по умолчанию. Для всех остальных операционных систем надо:
1. Стартовать службу WinRM и поставить ее на автозапуск;
2. Создать прослушиватель (listener), который будет слушать запросы на управление;
3. Включить на файерволе правило, разрешающее трафик WS-Management.
Для настройки одного компьютера проще всего использовать командлет Enable-PSRemoting. Он произведет все необходимые действия, а также зарегистрирует конфигурации сессии по умолчанию. Для того, чтобы подавить запросы на подтверждение, можно добавить параметр -force. Консоль необходимо запустить с правами администратора, иначе будет выдана ошибка.
В доменной среде для настройки PS Remoting можно воспользоваться групповыми политиками.
В разделе Computer Configuration\Policies\Windows Settings\System Services включим политику «Windows Remote Management (WS-Management)». Она задает режим запуска для службы WinRM.
В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включаем политику «Allow automatic configuration of listeners», которая создает прослушиватель на порту 5985 (порт для HTTP по умолчанию). Дополнительно можно указать, с каких IP можно принимать подключения. Если в фильтрации по IP нет необходимости, просто ставим знак *, что означает принимать подключения с любого адреса.
Затем идем в раздел Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules и создаем новое правило. Выбираем пункт Predefined (Предопределенные правила) и в списке выбираем Windows Remote Management.
Обратите внимание, что можно выбрать два режима работы — стандатный и совместимый. В первом случае будет открыт порт 5985, использующийся WinRM по умолчанию, во втором — порт 80 (для совместимости со старыми версиями WinRM). По умолчанию выбраны оба.
Настройка доверия между компьютерами
При удаленном подключении в PowerShell используется взаимная аутентификация между компьютерами. Это означает, что перед установлением соединения удаленная машина должна подтвердить свою подлинность. Проще говоря, если вы подключаетесь к компьютеру с именем SRV1, то перед установкой соединения он (SRV1) должен вам доказать, что это действительно он, иначе подключение не будет установлено.
Если компьютеры являются членами одного домена, или находятся в разных, но доверяющих друг другу доменах, то взаимная аутентификация будет выполнена доменными службами. Главное, чтобы имя компьютера разрешалось в IP-адрес и соответствовало имени компьютера в Active Directory.
Внимание: при подключении нужно указывать действительные имена компьютеров, т.е. так как они указаны в Active Directory. Если компьютер входит в локальный домен, то можно указать просто имя компьютера, например SRV1. Для указания имени компьютера из другого домена надо указать полное доменное имя (FQDN) — SRV1.contoso.com. Если же указать IP-адрес, или некоторое другое DNS-имя (например CNAME алиас), то взаимная аутентификация не сработает.
Если же один или оба компьютера не входят в домен, то для взаимной аутентификации есть два варианта: добавить удаленную машину в список доверенных узлов (Trusted Hosts) или использовать SSL.
Trusted Hosts
Добавление компьютера в Trusted Hosts — путь простой, но менее безопасный. Для компьютеров, находящихся в Trusted Hosts взаимная аутентификация фактически отключена. Поэтому пользоваться этим способом стоит с большой осторожностью.
Добавить компьютер в доверенные узлы можно с помощью PowerShell. Так для того, чтобы создать список доверенных хостов и добавить в него компьютер SRV1 воспользуемся командой:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value SRV1.contoso.com
При добавлении нескольких компьютеров их имена можно перечислить через запятую. Допускается указывать не только имя, но IP-адрес компьютера. Также поддерживаются символы подстановки. Например, можно добавить в доверенные хосты все компьютеры из домена contoso.com, указав значение *.contoso.com, или вообще всех без исключения:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value *
Чтобы добавить имя компьютера в уже имеющийся список доверенных узлов, необходимо сначала сохранить текущее значение в переменной, а затем присвоить значение разделенному запятыми списку, который включает текущее и новое значения. Например, чтобы добавить компьютер SRV2 в имеющийся список доверенных узлов, воспользуйтесь следующей командой:
$curr = (Get-Item WSMan:\localhost\Client\TrustedHosts).value
Set-Item WSMan:\localhost\Client\TrustedHosts -Value ″$curr,SRV2.contoso.com″
Ну и посмотреть список доверенных узлов можно командой:
Get-Item WSMan:\localhost\Client\TrustedHosts
Также для добавления в TrustedHosts можно воспользоваться групповой политикой. В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Client включаем политику «Trusted Hosts» и добавляем имена или IP-адреса компов через запятую. Поддерживаются подстановочные символы.
Примечание: если TrustedHosts сконфигурированы через GPO, то из PS изменить их не удастся. То же касается и всех остальных настроек PS Remoting.
SSL
Подключение с использованием SSL является наиболее защищенным вариантом удаленного взаимодействия. Но по сравнению с остальными способами он довольно сложен в настройке, так что придется немного повозиться.
Во первых, для использования этого метода, нам нужен цифровой сертификат SSL для машины, к которой мы собираемся подключаться. Получение сертификата — отдельная тема, не будем на ней останавливаться. В тестовой среде я воспользуюсь утилитой Makecert, входяшей в состав Windows SDK, и создам самоподписанный сертификат:
makecert -a sha1 -r -pe -n ″CN=wks8″ -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp ″Microsoft RSA SChannel Cryptographic Provider″ -sy 12 -m 12 ″C:\myssl.cer″
Эта команда создаст SSL-сертификат сроком на год и поместит его в хранилище сертификатов локального компьютера. Обратите внимание, что сертификат должен быть выдан на то же имя, которое вы будете указывать в команде подключения.
После получения сертификат должен быть добавлен в Trusted Root Authority (доверенные корневые центры сертификации). Для этого открываем сертификат и жмем на кнопку «Установить сертификат».
Запускается мастер импорта сертификатов. Указываем расположение хранилища «Локальный компьютер».
В качестве хранилища выбираем «Доверенные корневые центры сертификации».
Теперь наш сертификат является доверенным. Еще раз открываем его, и на вкладке «Состав» находим отпечаток сертификата (CertificateThumbprint). Копируем его в буфер обмена.
Теперь можно создавать прослушиватель для HTTPS. Открываем консоль PowerShell и вводим команду:
New-WSManInstance winrm/config/listener -SelectorSet @{ Address=′*′; Transport=′HTTPS′ } -ValueSet @{ HostName=′wks8′; CertificateThumbrint=′xxx′}
В поле CertificateThumbrint вставляем отпечаток сертификата, скопированный в предыдущем пункте.
Исключения файерволла Windows (если он включен) для нового прослушивателя необходимо настраивать вручную, автоматически они не создадутся. Поэтому создадим новое правило для входящего трафика по портам TCP 5986 и 443:
New-NetFirewallRule -DisplayName ″Windows Remote Management (HTTPS)″ -Direct Inbound -Protocol TCP -LocalPort 5986,443 -Action Allow -Enabled True
Также для создания правила можно воспользоваться графической оснасткой или утилитой командной строки netsh, кому что больше нравится.
Далее идем на компьютер SRV1, с которого будем подключаться. Поскольку я использую самоподписанный сертификат, то его придется добавить к доверенным корневым сертификатам и на клиенте. Копируем файл сертификата myssl.cer на SRV1 и устанавливаем командой:
certutil -addstore root C:\myssl.cer
Вот и все, настройка закончена. Теперь можно подключаться. Откроем интерактивную сессию на wks8 командой:
Enter-PSSession -ComputerName wks8 -Credential wks8\kirill -UseSSL
Обратите внимание, что при подключении по SSL необходимо вводить учетные данные, а также указывать тип подключения. Дальше все как обычно.
Отключение проверки
При подключении по SSL проверяется, что сертификат был выдан доверенным центром сертификации и выпущен именно для этой машины. Проще говоря, имя в сертификате должно соответствовать имени, указанному в команде подключения, а издатель сертификата должен быть в списке доверенных корневых центров сертификации. Если при проверке будет найдено несоответствие с этими условиями, то подключение не состоится.
В принципе это правильно, но при необходимости проверки можно отменить. Для этого в свойствах сессии есть два параметра:
-SkipCACheck — отменяет проверку издателя сертификата;
-SkipCNCheck — отменяет проверку соответствия имени компьютера.
Создать новую сессию с использованием этих параметров можно например вот так:
$option = New-PSSessionOption -SkipCACheck -SkipCNCheck
Enter-PSSession -ComputerName wks8 -SessionOption $option -Credential wks8\kirill -UseSSL
Правда в этом случае теряется смысл SSL-сертификатов, и тогда уж проще пользоваться Thrusted Hosts. Но возможность такая есть, и знать о ней надо.
Дополнительные настройки
Начиная со второй версии, WinRM по умолчанию слушает порт 5985 для HTTP и 5986 для HTTPS. Для совместимости со старыми версиями (или чтобы не открывать дополнительные порты на брандмауэре) можно дополнительно включить прослушиватели на традиционных портах 80 и 443. Для HTTP:
Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpListener $true
И для HTTPS:
Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener $true
То же самое можно сделать с помощью групповых политик. Для этого надо в разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включить политики «Turn On Compatibility HTTP Listener» и «Turn On Compatibility HTTPS Listener».
Порты по умолчанию можно изменить и указать слушать любой нестандартный порт, например порт 8080:
Set-Item WSMan:\localhost\listener\listener*\port -Value 8080
Примечание: установка прослушивателей на нестандартных портах несколько повысит безопасность. Однако имейте в виду, что изменив дефолтный порт, придется каждый раз при подключении указывать его вручную.
На этом все. Во второй части статьи рассмотрим конфигурации удаленных сессий, создание конечных точек (endpoint), ну и что нибудь еще по мелочи 🙂