Powershell 从调用的脚本运行 cmdlet

Question

我有一个调用另一个脚本(带参数)的脚本。调用的脚本包含 Install-WindowsFeature cmdlet。当我运行脚本时，被调用的脚本运行，但返回以下错误:

Install-WindowsFeature : The term 'Install-WindowsFeature' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path

当然，我可以从 PowerShell 控制台很好地运行 cmdlet。我还可以从 PowerShell 控制台和 Install-WindowsFeature 运行调用的脚本。工作正常。那么，这与从运行 cmdlet 的脚本调用脚本有关吗？这是我的调用代码:

$script = "C:\Path\script.ps1"
$argumentList = @()
$argumentlist += ("-Arg1", "value")
$argumentlist += ("-Arg2", "value")
$argumentlist += ("-Arg3", "value")
Invoke-Expression "$script $argumentList"

在被调用的脚本中，我调用了 Install-WindowsFeature如下:

if ($someValue) { Invoke-Command -ScriptBlock {Install-WindowsFeature -Name RSAT-AD-Tools} }

我也试过如下:

if ($someValue) { Install-WindowsFeature -Name RSAT-AD-Tools }

16 年 12 月 16 日编辑:此脚本在使用 Sapien PowerShell Studio 构建的 GUI 中运行。当我将构建类型更改为“ native ”时，它可以工作。我必须重置我的实验室才能检查，但我怀疑如果我只是在 x64 上下文中运行它，它也会运行。 This文章解释了为什么我认为这很重要。

在 Windows Server 2012 R2 上运行

Answer 1

除非你有一个令人信服的理由，否则让我们看看我们是否可以稍微清理你的调用模式 - 并希望通过避免扭曲来解决你的其他问题。

与其将参数列表创建为字符串，不如利用 parameter splatting .摆脱将 PowerShell 视为其他不能处理对象的脚本语言的习惯是很好的。

$splat = @{ 
    Arg1 = "value1";
    Arg2 = "value2";
    Arg3 = "value3"
    }

& c:\path\script.ps1 @splat

在 script.ps1 上使用它，如下所示:

param(
    $Arg1,
    $Arg2,
    $Arg3
)

Write-Host "Arg1 = $Arg1, Arg2 = $Arg2, Arg3 = $Arg3

您将获得以下预期输出:

Arg1 = value1, Arg2 = value2, Arg3 = value3

一旦你明白了，可能没有理由在调用 Install-WindowsFeature 时使用 Invoke-Command，除非你遗漏了诸如远程调用服务器之类的细节。 Invoke-Command { Install-WindowsFeature } 在使用 PowerShell 5 的 Server 2012R2 上对我来说仍然可以正常工作，而且没有理由不这样做。

正如其他评论所指出的，这假设您在支持 Install-WindowsFeature 的服务器上运行此脚本。客户端 Windows 不支持 Install-WindowsFeature，并且 RSAT 工具是通过独立的 RSAT .MSU ​​包安装的，您可以通过不同的方式对其进行管理。

Install-WindowsFeature 在 Server 2012R2 上随服务器管理器原生提供 - 无需 Import-Module... 除非您对配置文件进行了某些操作或弄乱了模块文件夹。 Windows Server 的早期版本之一需要它 - 但那是几个版本。同样，Add-WindowsFeature 是旧名称 - 它仍然可以作为 Install-WindowsFeature 的别名使用。

我假设您已经直接从命令行尝试了 Install-WindowsFeature 以确保它正常工作，并且 Get-Module Install-WindowsFeature 看起来很合理。

PS C:\Windows\system32> get-module ServerManager

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     2.0.0.0    ServerManager                       {Get-WindowsFeature, Install-WindowsFeature, Uninstall-Win...

当我们讨论这个话题时，几乎没有理由在支持 Install-WindowsFeature 的服务器上使用 DISM，并且有很多理由不这样做。

服务器管理器和其他几个工具(包括 Win32_ServerFeature)依赖于由 Install-WindowsFeature 使用的 WMI 提供程序解析和理解的功能状态。可以使用 DISM 启用正确的功能集，但需要注意和细节。仅启用角色和功能的“部分”可能会在特定情况下获得您想要的功能，但角色或功能可能不会显示为已安装在 Get-WindowsFeature 中，可能无法通过 Remove-WindowsFeature 卸载，并且可能不提供相关服务器管理器中的 UI 功能，例如监视角色的健康状况、查看相关事件或提供管理它的工具。

Install-WindowsFeature 与您正在安装的角色和功能中的其他代码集成，并且可能会运行其他运行状况和先决条件检查以确保您正确配置。

DISM 功能名称往往比服务器管理器的角色和功能名称更频繁地更改，因此您的脚本可移植性会更好。
还有其他要点，但我不会深入讨论，因为 DISM 主要是一个评论分支。