Как мне разместить скрипт или приложение Powershell, чтобы он был доступен через WSManConnectionInfo?(например, Office 365) - PullRequest
Новая
       20

Как мне разместить скрипт или приложение Powershell, чтобы он был доступен через WSManConnectionInfo?(например, Office 365)

19 голосов
/ 27 марта 2012

Единственные известные мне способы подключения к удаленному пространству выполнения включают в себя следующие параметры 

   WSManConnectionInfo connectionInfo = 
     new WSManConnectionInfo(false, "localhost", 80, "/Powershell", "http://schemas.microsoft.com/powershell/Microsoft.Exchange", credential);

или 

   WSManConnectionInfo connectionInfo = 
     new WSManConnectionInfo(false, "localhost", 5985, "/wsman", "http://schemas.microsoft.com/powershell/Microsoft.Powershell", credential);

  • Как настроить свои собственныепользовательский объект Powershell, чтобы я мог выставить его через HTTP?

  • Как правильно использовать параметры и как их настроить?

1 Ответ

20 голосов
/ 05 мая 2015

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

Неявное удаленное взаимодействие

Exchange использует Неявное удаленное взаимодействие .

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

Это делается с помощью Import-Module -Session $session или Import-PSSession.

Вы можете попробовать это сами в Powershell. Используйте рабочую станцию, на которой не установлен RSAT Active Directory (не имеет командлетов PowerSirectory PowerShell), затем подключитесь к машине, которая имеет (назовем это DC1): 

$s = New-PSSession -ComputerName DC1
Invoke-Command -Session $s -ScriptBlock { Import-Module ActiveDirectory }
Import-PSSession -Session $s -Module ActiveDirectory

Ограничение вызова на Import-PSSession только одним модулем позволяет импортировать только эти командлеты. К этому моменту вы сможете, например, выполнить Get-ADComputer, как если бы оно было доступно локально, даже если фактический вызов выполняется на DC1.

Конфигурации сеанса

Когда вы устанавливаете удаленное соединение PowerShell, вы подключаетесь к конфигурации сеанса. Если вы не укажете один, вы подключитесь к одному с именем Microsoft.PowerShell. Чтобы увидеть все конфигурации, определенные на машине, позвоните Get-PSSessionConfiguration. Вы можете увидеть некоторые другие, например, Microsoft.PowerShell32 - это способ подключения к 32-разрядному сеансу PowerShell.

Чтобы подключиться к определенной конфигурации, используйте New-PSSession -ConfigurationName или New-PSSession -ConnectionUri.

Определение конфигураций сеанса

Вы можете указать lot вещи в конфигурации сеанса; версия powershell, разрядность, какие модули предварительно импортированы, вы можете предварительно определить функции и код, вы можете запретить доступ к языковым функциям и т. д.

Этот ответ дает хороший обзор того, как создать собственную конфигурацию .

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

Код упаковки в модулях

Как вы видели с Import-PSSession, проще импортировать именно тот код, который вы хотите, если он существует в модуле. Поэтому вы должны убедиться, что ваш командлет доступен через модуль.

Вы сказали в комментарии, что хотите написать свой командлет на C #. Это не то, что я сделал, но эта статья содержит подробные инструкции по , как создать модуль PowerShell в C # .

Это то, что я сделал (и эта статья хороша). Написание командлета на C # неявно уже является модулем. Фактически, вы можете использовать Import-Module для загрузки скомпилированной сборки .NET, независимо от того, содержит ли она какие-либо командлеты PowerShell или нет.

Например, если вы создали открытый класс и скомпилировали его в DLL, вы можете сделать Import-Module MyAssembly.dll, и этот класс теперь доступен в вашем сеансе PowerShell.

Определение командлета в C # означает включение ссылки на System.management.Automation, а затем создание класса, который наследуется от Cmdlet или PSCmdlet.

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

Тем не менее, я не включил информацию о конфигурации сеанса в сборку (пока?), И не увидел справку о том, как это сделать.

Собираем все вместе

Шаги должны примерно напоминать это:

  1. Скомпилируйте модуль и сделайте его доступным на удаленном конце, чтобы его можно было импортировать в powershell из локального сеанса на этом компьютере.
  2. Создайте новый файл конфигурации PSSession и укажите либо -AssembliesToLoad, либо -ModulesToImport (или оба, если необходимо), либо , чтобы указать информацию о конфигурации в самой сборке (вероятно, предпочтительнее здесь).
  3. Зарегистрировать конфигурацию на машине.
  4. На стороне клиента вы хотели сделать его доступным для PowerShell, поэтому вы просто создадите сеанс и импортируете его: 
    $s = New-PSSession -ComputerName RemoteMachine -ConfigurationName MyConfig
    # The configuration was defined in such a way 
    # that your module will already be imported in the remote session.
    Import-PSSession -Module MyModule

Упрощение этого?

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

$s = New-PSSession -ComputerName RemoteMachine
Invoke-Command -Session $s -ScriptBlock { Import-Module MyModule }
Import-PSSession -Session $s -Module MyModule

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

...