它引入了许多非常有用的新概念,从而进一步扩展了您在 Windows 命令提示符和 Windows Script Host 环境中获得的知识和创建的脚本。
Windows PowerShell v3将伴随着MicrosoftHyper-V3.0和Windows Server 2012发布。PowerShell v3是一个Windows任务自动化的框架,它由一个命令行shell和内置在这个.NET框架上的编程语言组成。
PowerShell v3采用新的cmdlet让管理员能够更深入到系统进程中,这些进程可以制作成可执行的文件或脚本(script)。一条cmdlet是一条轻量命令,Windows PowerShell运行时间在自动化脚本的环境里调用它。Cmdlet包括显示当前目录的Get-Location,访问文件内容的Get-Content和结束运行进程的Stop-Process。
PowerShell v3在Windows Server 8中装载了Windows Management Framework 3.0。PowerShell运行时间也能嵌入到其它应用。
- Power Shell
- Windows/.NET
- 命令行工具
- 微软 Microsoft
目录
目标受众编辑
Windows PowerShell 入门主要面向之前没有 Windows PowerShell 背景知识的 IT 专业人员、程序员和高级用户。虽然具备脚本和 WMI 方面的背景知识会有所帮助,但是理解本文档并不假定或要求您具备此方面知识。
关于 Windows PowerShell
通过解决长期存在的问题并添加一些新的功能,Windows PowerShell 旨在改进命令行和脚本环境。PowerShell以.NET Framework为平台,接收和返回.NET对象,此举为管理和配置微软系统带来了新的方法和工具。
产品特性编辑
您可轻易发现 Windows Powershell 的功能。例如,若要查找用于查看和更改Windows 服务的cmdlet 列表,执行:开始->运行->cmd,在命令行下输入 PowerShell 进入 windows PowerShell,再输入如下命令:
get-command *-service
在发现可完成任务的 cmdlet 之后,可以使用 Get-Help cmdlet 了解有关该 cmdlet 的详细信息。例如,若要显示有关 Get-Service cmdlet 的帮助,请键入:
get-help get-service
若要充分理解该 cmdlet 的输出,则可通过管道将其输出传递给 Get-Member cmdlet。例如,以下命令将通过 Get-Service cmdlet 显示有关该对象输出的成员的信息。
get-service | get-member
一致性
管理系统可能是一项复杂的任务,而具有统一接口的工具将有助于控制其固有的复杂性。然而,无论是命令行工具还是可编写脚本的 COM 对象,在一致性方面都乏善可陈。
Windows PowerShell 的一致性是其主要优点中的一项。例如,如果您学会了如何使用 Sort-Object cmdlet,则可利用这一知识对任何 cmdlet 的输出进行排序。而无需了解每个 cmdlet 的不同的排序例程。
此外,cmdlet 开发人员也不必为其 cmdlet 设计排序功能。Windows PowerShell 为他们提供了框架,而该框架可提供基本的功能,并强制他们在接口的许多方面保持一致。该框架虽然消除了通常会留给开发人员的某些选项,但作为回报,开发强健、易于使用的 cmdlet 的工作将更加简单。
交互式脚本环境
Windows PowerShell 将交互式环境和脚本环境组合在一起,从而允许您访问命令行工具和 COM 对象,同时还可利用 .NET Framework 类库 (FCL) 的强大功能。
此环境对 Windows命令提示符进行了改进,后者提供了带有多种命令行工具的交互式环境。此外,还对 Windows Script Host (WSH)脚本进行了改进,后者允许您使用多种命令行工具和 COM 自动对象,但未提供交互式环境。
通过将对所有这些功能的访问组合在一起,Windows PowerShell 扩展了交互用户和脚本编写者的能力,从而更易于进行系统管理。
尽管您可以通过以文本方式键入命令与 Windows PowerShell 进行交互,但 Windows PowerShell 是基于对象的,而不是基于文本的。命令的输出即为对象。可以将输出对象发送给另一条命令以作为其输入。因此,Windows PowerShell 为曾使用过其他外壳程序的人员提供了熟悉的界面,同时引入了新的、功能强大的命令行范例。通过允许发送对象(而不是文本),它扩展了在命令之间发送数据的概念。
易于过渡到脚本
使用 Windows PowerShell,您可以很方便地从以交互方式键入命令过渡到创建和运行脚本。您可以在 Windows PowerShell命令提示符下键入命令以找到可执行任务的命令。随后,可将这些命令保存到脚本或历史记录中,然后将其复制到文件中以用作脚本。
识别你即将使用的Provider 通过识别PowerShell里安装的Provider,你就可以了解默认安装下PowerShell提供了那些能力。 Provider可以使用一种简单的访问方式,暴露位于不同储存位置的数据。就像是浏览不同磁盘上的目录结构一样简单。 Provider把不同的信息存放位置,表示成“驱动器”-目录这种结构,这样很容易被用户所理解。就像我们要访问一个位于D盘的WIN32目录下的SETUP.exe文件,我们要通过浏览器,单击D盘的图标,然后选择WIN32目录并双击一样,如果我们要访问位于“注册表”的数据,那么我们也只需要简单地通过Set-Location命令,来到到“REGISTRY”这个“驱动器”,然后用GET-CHILDITEM命令获取其子数据就行了。
注:实际上,PowerShell访问磁盘驱动器,也是通过Provider的,切换驱动器其实和切换其他数据容器是一样地操作。 例如: Set-Location d:\ 这是切换驱动器 Set-Location HKLM:\ 这是切换到注册表的HKLM键 另外,Get-PSprovider命令,可以查看当前已经安装的所有PROVIDER。任何熟悉.NET编程的人,都可以编写Provider。当新的provider被安装后,就叫做snap-in。snap-in其实是一个动态连接库dll文件,可以被安装到powershell中。然而,当一个snap-in安装后,却没有办法卸载。 Get-PSProvider: Name Capabilities Drives ---- ------------ ------ Alias ShouldProcess {Alias} Environment ShouldProcess {Env} FileSystem Filter, ShouldProcess {C, D, F, A...} Function ShouldProcess {Function} Registry ShouldProcess {HKLM, HKCU} Variable ShouldProcess {Variable} Certificate ShouldProcess {cert} 这些就是我机器上的默认安装后的provider。
使用Set-Location和Get-ChildItem浏览数据 Set-Location用于改变当前目录,以及选择当前的provider,而Get-ChildItem用于获取当前目录或者指定目录下的子对象: 例子: set-location hkcu:\software get-childitem 例子2: GCI -path HKLM:\software
有两种连接WMI服务的方法:l 使用Get-WmiObject可以很容易地连接到WMI服务,并且获取WMI对象。 l 使用一个COM对象,“WbemScripting.SWbemLocator”,可以连接WMI的服务。SWbemLocator对象只有一个方法,就是ConnectServer()。该方法接受5个参数:用户名,密码,语言代码,验证方法(Kerberos, NTLM等),标志(超时值)。
下例中,我们使用New-Object命令,创建了一个“WbemScripting.SWbemLocator”的实例。然后用这个实例的ConnectServer方法连接了到了一个WMI的名字空间(root\cimv2),ConnectServer方法返回了一个WMIService对象,接着又用这个对象的subClassesOf()方法,返回了一系列WMI的CLASS: $strComputer = "." $wmiNS = "\root\cimv2" $strUsr ="" #Blank for current security. Domain\Username $strPWD = "" #Blank for current security. $strLocl = "MS_409" #US English. Can leave blank for current language $strAuth = "" #if specify domain in strUsr this must be blank $iFlag = "0" #only two values allowed: 0 and 128. $objLocator = New-Object -comobject "WbemScripting.SWbemLocator" $objWMIService = $objLocator.ConnectServer($strComputer, ` $wmiNS, $strUsr, $strPWD, $strLocl, $strAuth, $iFLag) $colItems = $objWMIService.subClassesOf() Write-Host "There are: " $colItems.count " classes in $wmiNS" foreach ($objItem In $colItems) { $objItem.path_.class }
新脚本语言
由于以下原因,Windows PowerShell 使用它自己的语言,而不是重用现有的语言:
Windows PowerShell 需要用于管理.NET 对象的语言。该语言需要为使用cmdlet 提供一致的环境。该语言需要支持复杂的任务,而不会使简单的任务变得更复杂。 该语言需要与在.NET编程中使用的高级语言(如C#)一致。
1、PS1文件
一个PowerShell脚本其实就是一个简单的文本文件,这个文件包含了一系列PowerShell命令,每个命令显示为独立的一行,对于被视为PowerShell脚本的文本文件,它的文件名需要使用.PS1扩展。
2、执行权限
为防止恶意脚本的执行,PowerShell有一个执行策略,默认情况下,这个执行策略被设为受限的(Restricted),意味着PowerShell脚本无法执行,你可以使用下面的cmdlet命令确定当前的执行策略:
Get-ExecutionPolicy 你可以选择使用的执行策略有:
Restricted -脚本不能运行。 RemoteSigned - 本地创建的脚本可以运行,但从网上下载的脚本不能运行(除非它们拥有由受信任的发布者签署的数字签名)。 AllSigned – 仅当脚本由受信任的发布者签名才能运行。 Unrestricted –脚本执行不受限制,不管来自哪里,也不管它们是否有签名。
你可以使用下面的cmdlet命令设置PowerShell的执行策略:
Set-ExecutionPolicy <policy name>
3、运行脚本
如果你想从命令行运行一个可执行文件,多年来一个永恒不变的方法是,在命令行转到该执行文件所在的位置,然后键入该执行文件的名称,但这个古老的方法现在却不能适用于PowerShell可执行脚本了。
如果你想执行一个PowerShell脚本,通常必须键入完整的路径和文件名,例如,假设你要运行一个名为a.ps1的脚本,你可以键入:
.\a.ps1 注意前面需要加上.\,这和Linux下执行Shell脚本的方法如出一辙。
4、管道
管道的作用是将一个命令的输出作为另一个命令的输入,两个命令(或cmdlet)之间只需要用管道符号(|)连接即可。
为了帮助你了解管道是如何工作的,我们以一个例子进行说明,假设你想创建运行在服务器上的进程列表,并按进程的ID号进行排序,可以使用Get-Process cmdlet命令获得进程列表,但默认情况下列表不会排序,如果将这个cmdlet命令的输出用管道输送给Sort-Object ID命令,进程列表将会按进程ID号进行排序,如:
Get-Process | Sort-Object ID
5、变量
虽然可以使用管道将一个命令的输出输送给另一个命令,但管道本身也是有限制的,当你用管道从一个命令向另一个命令传递输出结果时,输出结果立即被使用,但有时候,你可能需要保存输出结果一段时间,以便以后可以使用(或重用),这个时候管道就应该下场,轮到变量上场了。
人们很容易将变量想象成一个仓库,但在PowerShell中,变量可以保存命令的完整输出,例如,假设你想保存服务器处于运行中的进程列表,你可以将它赋给一个变量,如:
$a = Get-Process 在这里,变量被命名为$a,如果你想使用这个变量,只需要简单地调用它的名称即可,例如,键入$a便可在屏幕上打印变量的内容。
你可以将多个用管道连接的命令的最终输出赋给一个变量,只需要用一对小括号将命令括起来即可,例如,假设你想按进程ID对运行中的进程进行排序,然后将结果输出给一个变量,你可以使用下面这个命令:
$a = (Get-Process | Sort-Object ID)
6、@符号
通过使用@符号,你可以将列表内容转换成一个数组,例如,下面的代码创建了一个名为$Procs的变量,它包含多行文本内容(一个数组):$procs = @{name="explorer","svchost"}
使用变量时你也可以使用@符号,为了确保它作为数组而不是单个值处理,例如,下面的代码将在我前面定义的变量上运行Get-Process cmdlet命令:
7、Split
Split操作符根据你指定的字符拆分一个文本字符串,例如,假设你想将一个句子拆分成一个单词组成的一个数组,你可以使用下面的命令做到:
"This is a test" -split " " 拆分后的结果如下:
This is a test
8、Join
就像Split可以将一个文本字符串拆分成多块一样,Join的操作则是逆向的,将多个独立的块连接成一个整体,例如,下面这行代码将会创建一个文本字符串,由我的名字和姓氏组成:
"Brien","Posey" -join " " 命令末尾双引号之间的空格告诉Windows在两个文本字符串之间插入一个空格。
9、断点
运行一个新创建的PowerShell脚本时,如果脚本有Bug,会遇到意想不到的后果,保护自己的一个方法是在脚本的关键位置插入断点,这样你就可以确保脚本正常运行先,然后再处理可能存在的问题。
插入断点最简单的方法是根据行号插入,例如,假设你要在第10行插入一个断点,可以使用下面的命令:
New-PSBreakpoint -Script C:\Scripts\a.ps1 -Line 10 你也可以将断点绑定到变量上,如果你希望你的脚本任何时候都可以修改a$的内容,可以使用下面的命令:
New-PSBreakpoint -Script C:\scripts\a.ps1 -variables a 注意,我在变量名后并没有包括美元符号。
可以和PSBreakpoint一起使用的动词包括New,Get,Enable,Disable和Remove。
10、Step
调试一个脚本时,有时可能需要逐行运行脚本,这时你可以使用Step-Into cmdlet命令,它会使脚本一行一行地执行,不管有没有设置断点,如果你想从这种步进式运行模式退出来,使用Step-Out cmdlet命令即可,但需要注意的是,使用Step-Out cmdlet命令后,断点仍然有效。
顺便说一句,如果你的脚本使用了函数,你可能对Step-Out cmdlet更感兴趣,Step-Out的工作方式和Step-Into一样,不过,如果调用了一个函数,Windows不会逐步执行,整个函数将会一次性执行。
优缺点编辑
优点
PowerShell v3
PowerShell v3将在PowerShell上打造管理的大部分,也提供GUI管理选项以及命令行自动化。v3引入了一些相当重要的新功能。
更好的远程处理
PowerShell远程已经逐渐成为在网络上进行管理通信的主要渠道。越来越多的GUI管理控制台将依赖远程,因此加强PowerShell远程对微软很重要。现在能够断开远程会话,稍后能从同个或不同的计算机重新连接到相同的会话。客户端计算机崩溃的话,v3的社区技术预览版不能断开会话。相反,会话会永久关闭。所以这与远程桌面完全不同,远程桌面会话能在客户端崩溃时配置并打开会话。
本质上,PowerShell新的工作流构建能写入与功能类似的东西,使用PowerShell翻译命令和脚本代码到Windows工作流技术WWF进程中。WWF然后能管理整个任务,包括修复网络故障与重启计算机等。它是编排长期运行的、复杂的、多步骤任务的更有效更可靠的一种方式。如果这个功能与下一个版本的System Center Orchestrator集成。
可更新的帮助
PowerShell与帮助文件中的错误做斗争。微软需要发布一个操作系统补丁。基于TechNet站点的在线帮助的存在减轻了这个问题,但杯水车薪。在v3中,帮助文件能按需更新,从任何微软服务器都可下载新的XML文件。所以微软就能根据找到的问题进行错误修复,不需要操作系统包或补丁。
预定任务(Scheduled Job)
owerShell v2引入了job,遵循的是job随着时间扩展的理念。在v3中,新型job即scheduled job能被创建并按计划运行,或者相应某个事件。这与Windows的Task Scheduler的区别只是其中一小点,不过最终用户能从PowerShell中获得这个功能。
更好的发现
关于命令行shell的一个困难部分在于如何使用。PowerShell的帮助系统很有用,需要提供用户想知道的命令的名字,并提供命令所在的插件名字,并记得加载附件到内存中。而PowerShell v3在搜索命令时,包含所有安装模块的所有命令,shell会运行没有装载的命令。这只能在那些存储在列于PSModulePath环境变量中的文件路径中的模块有用。如果要包含额外路径,可以在任何时候修改变量。
额外功能:CIM
PowerShell与Windows管理规范WMI运作很好,WMI是微软的一项技术,或多或少建立在标准的通用信息模块CIM上。在PowerShell v3中,WMI cmdlet发挥余热,加入到新的CIM cmdlet集中。功能看起来似乎有重叠:CIM cmdlet使用WS-MAN,这个协议位于PowerShell的Remoting功能,微软管理功能的新标准的后面。WMI使用被微软正式弃用的DCOM,意味着不会再开发新功能,但可一直使用。CIM是未来的方向,不仅有对已知WMI的额外开发,而且在未来还可跨平台管理。
缺点
PowerShell v3
新的Hyper-V 3.0 cmdlets不能管理老版本的Hyper-V。这意味着管理员根据Hyper-V的不同必须采用不同的脚本去管理,直至完成所有宿主机的升级。
Hyper-V 3.0和老版本不兼容。使用老版本Hyper-V的管理员需要从CodePlex下载PowerShell Library for Hyper-V。
创建事件日志编辑
管理员可以使用PowerShell创建一个新的事件日志,还可以查看事件日志的状态。
管理员可以使用PowerShell轻松地添加一个新的事件日志,例如,可以使用下面的代码创建一个名为TestSource的新的应用程序事件日志。
New-EventLog -LogName Application -Source TestSource
如果将信息写入该Windows事件日志中只需要调用EventLog的WriteEntry方法。具体代码如下:
Write-EventLog -LogName Application -EventId 1234 -Source TestSource -Message "Test write"
另外,你还可以通过使用Windows PowerShell快速查看关键Windows事件日志的配置状态和事件的数量。
Get-EventLog cmdlet里提供了-List参数,可显示出每个事件日志文件最大值和OverflowAction,以及目前的日志的数量。
下面看一则实例,输入cmdlet,按返回键得出以下内容:
PS C:\> Get-EventLog -List
Max(K) Retain OverflowAction Entries Log
------ ------ -------------- ------- ---
512 7 OverwriteOlder 149 ACEEventLog
20,480 0 OverwriteAsNeeded 38,796 Application
20,480 0 OvjerwriteAsNeeded 0 HardwareEvents
512 7 OverwriteOlder 0 Internet Explorer
20,480 0 OverwriteAsNeeded 0 Key Management Service
15,360 0 OverwriteAsNeeded 12,655 Operations Manager
20,480 0 OverwriteAsNeeded 36,084 Security
20,480 0 OverwriteAsNeeded 23,408 Systemb
15,360 0 OverwriteAsNeeded 18,305 Windows PowerShell
------ ------ -------------- ------- ---
512 7 OverwriteOlder 149 ACEEventLog
20,480 0 OverwriteAsNeeded 38,796 Application
20,480 0 OvjerwriteAsNeeded 0 HardwareEvents
512 7 OverwriteOlder 0 Internet Explorer
20,480 0 OverwriteAsNeeded 0 Key Management Service
15,360 0 OverwriteAsNeeded 12,655 Operations Manager
20,480 0 OverwriteAsNeeded 36,084 Security
20,480 0 OverwriteAsNeeded 23,408 Systemb
15,360 0 OverwriteAsNeeded 18,305 Windows PowerShell
Windows PowerShell 5.0编辑
Windows PowerShell 5.0中包含了大量的新特性和新功能,提升了整体的用户体验。
远程文件编辑功能
管理员暂时可以通过PowerShell建立与另一个Windows服务器的远程会话。新的远程文件编辑功能在此基础之上进行构建,从而能够建立一个远程会话,然后在远程计算机上编辑文件。
期望状态配置
PowerShell期望状态配置(DSC)是2013年下半年发布的Windows 8.1和Windows Server 2012 R2最终版本中默认自带的一个功能。它是一个基于标准Web服务的配置管理系统,允许你按照自己的方式对机器进行配置。
对于不熟悉期望状态配置的用户来说,改善后的功能允许管理员对比Windows服务器的期望状态,如果服务器出现问题并偏离了理想的配置,利于管理员及时采取修正措施。期望状态配置功能已经存在一段时间了,但微软添加了一个新的参数。新参数允许对期望状态配置功能设置节流阀限制。该理念在于期望状态配置功能通常与大量服务器同时运行。这样做会消耗大量的系统资源。节流阀限制允许管理员限制期望状态配置的并发数量,从而限制系统资源消耗。
也许PowerShell 5.0最受欢迎的一个变化是其接口——不是命令集。批评人士认为Windows PowerShell的复制粘贴功能可以产生一些不可预知的结果。微软已经完全修改了复制和粘贴的工作方式。[2]
PowerShell期望状态配置内置于Windows Server,所以它没有购买许可和系统管理、配置部署软件管理实例的额外开支。b
PowerShell期望状态配置几乎不需要代理,需求只是安装好PowerShell,并且可以通过80或者443端口查询Web服务器来抓取配置信息,这里不需要额外的配置系统管理开销。
PowerShell期望状态配置看起来只是配置文件定义的功能。它忽略其他设置,使配置负载更加轻巧和加速其他部署,这样它就可以定义多个配置和堆叠工d作负载(一台Web服务器也充当文件服务器,并且可以获取没有文件服务器设置覆盖的Web服务器的设置),这类部署是许多系统管理套件无法很容易地应付,甚至完全不能处理。[3]
Push模式和Pull模式的配置
PowerShell DSC的基本原则是使用定义所需配置的两种模式,这样管理员既可以自定义地有间隔地使机器从中央存储库获取正确配置信息,也可以将这类信息推送回去。
Push模式是一个主动的配置模式运行方式,当你发出“Start-DscConfiguration –Computername –Path”的PowerShell命令并且键入的命令带有“-Path”的属性时,就会立即触发存在任何位置的基于文件存储的系统配置推送出去。这几乎是一种即时执行“现在就做”的方式来管理你放在中央存储位置的所有配置文件目标和需求,这些文件可以让你计划的目标机器去访问。这个需要你设置经常去触发推动,并且默认配置不会自己检测。
Pull模式有一点点被动;它需要一台服务器同时为配置文件和其它为计算机各方面配置充当中介角色的构件提供清算服务。举个例子,在你编v写一个自定义服务提供程序——可以提供使用PowerShell DSC的一段代码——它可以转换本地自定义业务应用程序的配置文件中的指令。Pull服务器只是一台运行IIS的服务器,而IIS可以发布OData。OData是一种典型、明确定义以及标准支持的界面,通过这个界面PowerShell的Web 服务器可以获取到真正的配置数据。因此,Pull模式是实施PowerShell DSC最常用的方式,也可以用来部署当配置远离期望状态并且超时的情况。PowerShell DSC定期运行,下发正确的配置,执行静默的进程来更改配置为期望状态。
以上的这些配置定义都集成在管理对象文件或者MOF 文件,基本上都是一些文本文件,像一系列的classes,或者是一些PowerShell 配置引擎可以读懂的与Windows操作系统有关的一些元素,抑或是一些可以定义期望配置的classes参数。这里提供一些.MvOF配置行文件的参考:
instance of PowerPlan as $PP
{
ResourceID = "[PowerPlan] Default::[BaseServer]JustTheBasics::[VirtualServer]VMWare";
SourceInfo = "C:\\windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\SELocalConfiguration\\StackExchangeConfiguration\\StackExchangeConfiguration.psm1::20::5::PowerPlan";
Name = "High performance";
ModuleName = "PowerPlan";
ModuleVersion = "1.0";
};
MOF文件通常是手动建立一次,然后根据需求进行复制和粘贴。对于检测这个配置涉及的安装、移除或者确保某些Windows角色和功能是否已经存在,你可以使用内置命令Get-DscResource来检测。这个命令会根据你所以给出的角色或者功能名称,抓取出它们的正确使用语法和其他可用选项。例如,如运行上面的命令,就会显示PowerShell期望状态配置可以操作的“区域”配置类型,你可以在每个区域里面执行这一类的任务和任务指令。
Name Properties
---- ----------
File {DestinationPath, Attributes, Checksum, Con...
Archive {Devstination, Path, Checksum,z Credential...}
Environment {Name, DependsOn, Ensure, Path...}
Group {GroupName, Credential, DependsOn, Descript...
Log {Message, DependsOn}
Package {Name, Path, ProductId, Arguments...}
Registry {Key, ValueName, DependsOn, Ensure...}
Script {GetScript, SetScript, TestScript, Credenti...
Service {Name, BuiltInAccovunt, Credential, DependsO...
User {UserName, DependsOn, Description, Disabled...
WindowsFeature {Name, Credential, DependsOn, Ensure...}
WindowsProcess {Arguments, Path, Credential, DependsOn...}
正如你所看到的,这里有关于操作系统各方面的属性,从角色和功能到脚本、注册设置、认证,你都可以使用DSC来做控制。
这些都是PowerShell期望状态配置的基本要素。获取更多信息,查询PowerShell.org,特别是有标记的DSC资源[4]
Push模式是一个主动的配置模式运行方式,当你发出“Start-DscConfiguration –Computername –Path”的PowerShell命令并且键入的命令带有“-Path”的属性时,就会立即触发存在任何位置的基于文件存储的系统配置推送出去。这几乎是一种即时执行“现在就做”的方式来管理你放在中央存储位置的所有配置文件目标和需求,这些文件可以让你计划的目标机器去访问。这个需要你设置经常去触发推动,并且默认配置不会自己检测。
Pull模式有一点点被动;它需要一台服务器同时为配置文件和其它为计算机各方面配置充当中介角色的构件提供清算服务。举个例子,在你编v写一个自定义服务提供程序——可以提供使用PowerShell DSC的一段代码——它可以转换本地自定义业务应用程序的配置文件中的指令。Pull服务器只是一台运行IIS的服务器,而IIS可以发布OData。OData是一种典型、明确定义以及标准支持的界面,通过这个界面PowerShell的Web 服务器可以获取到真正的配置数据。因此,Pull模式是实施PowerShell DSC最常用的方式,也可以用来部署当配置远离期望状态并且超时的情况。PowerShell DSC定期运行,下发正确的配置,执行静默的进程来更改配置为期望状态。
以上的这些配置定义都集成在管理对象文件或者MOF 文件,基本上都是一些文本文件,像一系列的classes,或者是一些PowerShell 配置引擎可以读懂的与Windows操作系统有关的一些元素,抑或是一些可以定义期望配置的classes参数。这里提供一些.MvOF配置行文件的参考:
instance of PowerPlan as $PP
{
ResourceID = "[PowerPlan] Default::[BaseServer]JustTheBasics::[VirtualServer]VMWare";
SourceInfo = "C:\\windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\SELocalConfiguration\\StackExchangeConfiguration\\StackExchangeConfiguration.psm1::20::5::PowerPlan";
Name = "High performance";
ModuleName = "PowerPlan";
ModuleVersion = "1.0";
};
MOF文件通常是手动建立一次,然后根据需求进行复制和粘贴。对于检测这个配置涉及的安装、移除或者确保某些Windows角色和功能是否已经存在,你可以使用内置命令Get-DscResource来检测。这个命令会根据你所以给出的角色或者功能名称,抓取出它们的正确使用语法和其他可用选项。例如,如运行上面的命令,就会显示PowerShell期望状态配置可以操作的“区域”配置类型,你可以在每个区域里面执行这一类的任务和任务指令。
Name Properties
---- ----------
File {DestinationPath, Attributes, Checksum, Con...
Archive {Devstination, Path, Checksum,z Credential...}
Environment {Name, DependsOn, Ensure, Path...}
Group {GroupName, Credential, DependsOn, Descript...
Log {Message, DependsOn}
Package {Name, Path, ProductId, Arguments...}
Registry {Key, ValueName, DependsOn, Ensure...}
Script {GetScript, SetScript, TestScript, Credenti...
Service {Name, BuiltInAccovunt, Credential, DependsO...
User {UserName, DependsOn, Description, Disabled...
WindowsFeature {Name, Credential, DependsOn, Ensure...}
WindowsProcess {Arguments, Path, Credential, DependsOn...}
正如你所看到的,这里有关于操作系统各方面的属性,从角色和功能到脚本、注册设置、认证,你都可以使用DSC来做控制。
这些都是PowerShell期望状态配置的基本要素。获取更多信息,查询PowerShell.org,特别是有标记的DSC资源[4]
在远程服务器上运行Power Shell命令编辑
Windows Power Shell在用户管理和维护Windows方面是一个强大的命令行环境。虽然Windows Power Shell是一个本地管理工具,但是它也用于管理远程服务器。事实上,管理员可以针对大量的服务器创建Windows Power Shell脚本来执行管理任务。Invoke-Command和New-PSSession都是在远程服务器中Windows Power Shell的执行命令。
Invoke-Command
如果你只需要针对单台或者多台远程v服务器执行一个Windows Power Shell命令(或者一系列的管道命令),那么最便利的方法就是Windows Power Shell使用Invoke-Command命令。Microsoft的文档列出了绝大多数的参数和语法,导致人人皆知Invoke-Command命令的复杂性。即使如此,使用Invoke-Command在远程系统上执行Windows Power Shell命令仍然出奇地容易。
对于基本的Windows Power Shell远程命令执行,你只需要提供远程计算机的名称和想要执行的代码块。假设你想要在名称为Production1的远程服务器上执行Get-VM命令,你可以使用下面的Windows Power Shell命令:
Invoke-Command –ComputerName Production1 {Get-VM}
虽然Windows Power Shell看起来很简单,但是你也要对使用这个方法了解以下几点。
首先,Invoke-Command命令不限制你在一个远程系统上执行命令,你可以在多个计算机上指定命令,你需要做的就是使用命令区分开这些计算机的名称。例如,在Production1,Production2和Production3计算机上执行命令如下:
Invoke-Command –ComputerName Production1, Production2, Production3 {Get-VM}
第二点,你必须要知道虽然这个方式的设计目的只是简单地在单个远程系统上运行的单一Windows Power Shell命令,但是你也可以运行多个Windows Power Shell命令。如果查看之前的Windows Power Shell几行代码,你会注意到允许在远程计算机上运行的Get-VM命令是包含在花括号里面的。任何在花括号里面的Windows Power Shell命令都会在指定的远程计算机行运行。同样的,只要所有的Windows Power Shell命令都包含在花括号里面,你可以使用管道符号把Windows Power Shell命令把它们链接在一起。
第三点你必须知道上面的Windows Power Shell语法只有在所有计算机中使用了Kerberos认证才会运行,同时包括有命令输入和已经加入了域。否则,你必须使用HTTPS传输,并且必须指定远程系统是受信任的主机。
New-PSSessionv
New-PSSession通常用于在远程系统上执行Windows Power Shell命令。Invoke-Command命令设计于用于在远程系统上执行单一Windows Power Shell命令(或者一连串的Windows Power Shell命令),而New-PSSession实际上是用于在远程服务器上重定向PowerShell。实质上,你输入的任何Windows Power Shell命令都会自动发送到远程机器上运行。
例如Invoke-Command命令,这里有许多不同的New-PSSession命令变量,你可以从Microsoft官网文档中寻找这些变量。
这个命令如此简易,它只要求提供远程计算机的名称。例如,如果你想和名为Production1的计算机建立一个会话,你可以使用以下Windows Power Shell命令:
New-PSSession –ComputerName Production1
这个Windows Power Shell命令会与指定的计算机建立会话,但是它不会自动重定向任何你在远程计算机输入的执行PowerShell命令;原因是Microsoft并不限制你只使用一个远程会话。你可能需要和多个不同的服务器建立回话。因此,输入上述命令建立一个Windows Power Shell会话,PowerShell会提供确认的会话,也会罗列出一个会话ID号,但仅此而已。
如果你想要使用远程会话,那么你将不得不使用另一个名为 Enter-PSSession的Windows Power Shell,只是简单地附件上你想连接到会话ID号即可。例如,如果有一个连接到Production1,且会话ID为列名1的New-PSSession会话,你就可以输入一下命令来连接这个会话:
Enter-PSSession 1
当你在使用这个Windows Power Shell命令时,PowerShell会提示你为这个远程程系统更改一个相关的名称,这样你就可以很轻松地跟踪你正在发送命令的系统了。
再一次的,你需要确保使用了Kerberos认证,并且所有的系统都已经加入了域。否则,想要建立远程会话,你需要多加几个额外的步骤。
使用Windows Power Shell注销RDP编辑
Windows Power Shell已经不是一个新的问题了:终端Windows Power Shell用户通过远程桌面协议登录到一台Windows服务器后忘记退出,然后继续消耗服务器上的资源。这时,你可以使用Windows Power Shell脚本来强制终端用户注销并释放这些资源。
Windows Power Shell为了强迫用户注销远程桌面协议(RDP)会话,管理员必须首先了解该服务器上所有远程桌面服务(RDS)服务器会话,并查看它们的状态。检测所有服务均断开连接后,下一步才是强制下线。
下载Windows Power Shell模块PSTerminalServices,并确保在你的Windows Power Shell环境中可以使用。所有的安装说明都可在PSTerminalServices站点获得。
第一步,我要用这个Windows Power Shell模块来检查是否能得到实验室服务器HYPERV上的所有会话活动(图1)。
目前,只有几个Windows Power Shell会话处于断开状态。所以,可以看到所有的Windows Power Shell会话,但是只是想看到那些断开连接的Windows Power Shell。要做到这一点,将添加State参数(图2)。
这个Windows Power Shell方法很有用,但是仍然有一个问题。会话0不是一个RDP会话,无法用Get-TSSession将其从结果列表中删除。这时,使用Where-Object来删除该会话(图3)。
现在,可以看到所有想停止的Windows Power Shell会话。接下来,只需要杀死这些Windows Power Shell会话。要做到这一点,要知道PSTerminalServices模块提供了Stop-TSSession cmdlet,可以帮你杀死Windows Power Shell会话(图4)。
Stop-TSSession cmdlet结束Windows Power Shell会话后可能会导致最终用户丢失工作内容,因此会提示管理员。这里可以点击“A”继续下一步,但有时管理员不喜欢弹出Windows Power Shell提示信息。如果将这些放在一个更大的Windows Power Shell脚本中,提示将中断Windows Power Shell脚本。最好的办法是省略提示。
Stop-TSSession cmdlet有一个通用的Windows Power Shell参数,叫做–Force,Windows Power Shell允许管理员执行操作时没有任何确认信息打扰。
Get-TSSession -ComputerName HYPERV -State Disconnected | where {$_.SessionID -ne 0} | Stop-TSSession -Force
使用Windows Power Shell管理多个服务器编辑
对于使用Windows Power Shell及以上版本的大型微软应用软件环境下的系统管理员,很有可能日常都会面临管理Windows Power Shell角色管理的问题。Windows Power Shell服务器允许管理员通过点击功能窗口按钮来增加、删除或修改系统角色和功能,但是点击功能窗口大部份操作对于管理员来说不是自动完成的。这就是Windows Power Shell发挥作用的地方。
Windows Power Shell服务管理器是一个单独创建的用于管理服务器标识和系统信息的图形化用户界面(GUI)区域。Windows Power Shell通过管理接口允许管理员针对某个服务,Windows Power Shell通过点击功能键执行各种工作。虽然这种方法适合用于小规模的应用环境,但Windows Power Shell不适合大规模集群下的应用环境。通过Windows Power Shell命令行的方式就以简化这些操作。
Windows Power Shell有一个叫“ServFerManager”的模块,它包含了许多可以帮助管理系统角色和功能的命令(图1)。
将以2个别名和5个实际的Windows Powfer Shell命令和函数为例。为了更简洁,在文章中我们将直接使用这些命令/函数名字。开始之前,使用“Get-Windows Feature”命令确认系统中所有可用的系统角色和功能。
当不加参数地使用“Gevt-Windows Feature”命令,Windows Power Shell会输出系统中所有的系统角色和功能—不论现在Windows Power Shell是否在系统中安装。图2展示了在测试系统中的一些可用的功能。
Windows Power Shell对于现在系统中已经安装系统功能,可以使用“Where-Object”命令查看(图3)。
图3. Where-Object命令输出测试系统已安装的功能
如果想安装一个新的Windows Power Shell系统功能,应怎样做呢?可以使用“Install-Windows Feature”命令。例如想在我的本地服务器上安装SNMP服务,我可以使用“Install-Windows Feature”命令并且加上名字参数。如图5表示Windows Power Shell功能服务已安装完成。
可以使用“Remove-Windows Feature”命令来删除某些Windows Power Shell系统功能。删除Windows Power Shell系统功能就像安装Windows Power Shell某个功能一样容易,即加上命令的Name参数就行。
在图形化界面操作时需注意必须重启Windows Power Shell服务器才能完成删除某个系统功能。如果使用Windows Power Shell命令脚本的方式,可以不通过手动操作完成。“Install-Windows Feature”和“Remove-W?indows Feature”命令都有“remove”参数。如果有必要,Windows Power Shell可以执行完命令后自动重启服务器。
如果只有一台单独的Windows Power Shell服务器,本地化操作没有问题,但是可以通过使用Windows Power Shell服务管理器以相似的方式对多台Windows Power Shell服务器进行操作管理。使用Windows Power Shell远程管理功能,管理员可以使用“Computername”参数指定对远程任一个服务器进行操作,如图6:
如果想同时在100台Windows Power Shell服务器上安装一个Windows Power Shell系统功能应该怎样操作呢?如果把服务器信息写入一个文本文件中后,这就不是问题。如果在服务端有一个包含了Windows Power Shell服务器名字CSV文件,可以使用Windows Power Shell import命令来读取csv文件内容并且可以并发执行任何对Windows Power Shell系统功能的操作命令。
Import-Csv C:\Servers.csv | foreach { Install-WindowsFeature -Name 'SNMP-Service' -ComputerName $_.ServerName }
使用Windows Power Shell控制IT权限编辑
在Windows Power Shell受攻击面方面,IT安全专家经常谈论的话题是Windows Power Shell服务器和应用程序。尽管Windows Power Shell的大部分安全工作都是为了强化操作系统和应用程序以减少可能的受攻击面,但是有可能IT员工自己本身会成为受攻击面。
很多Windows Power Shell网络攻击利用了恶意软件来获取受害者系统的访问权限。像很多其他的软件一样,Windows Power Shell恶意软件也会受限于当前的安全环境。比如说,一个拥用基本Windows Power Shell用户权限的用户不小心运行了一个恶意软件会比一个管理员运行这个恶意软件带来的损坏小得多。
IT专家长期接受移除管理员Windows Power Shell权限来提高安全性的方法,但是剥夺所有IT员工的管理员Windows Power Shell权限并不是一个实用的方法。IT员工一定要有相应必需的Win~!dows Power Shell权限来执行他们的工作。
这就是需要用到Just Enough Administration的地方了。Just Enough Administration( JEA) 是一个Windows Power Shell工具包来帮助企业组织限制管理员权限,以提供自身Windows Power Shell整体安全性。
JEA是一种基于角色的访问控制形式。主要的方法是精确地授予IT员工他们工作必需的Windows Power Shell权限,不多也不少。即使如此,JEA也和传统的基于Windows Power Shell身份的访问控制不一样,传统的访问控制是基于一份详尽的权限集合夊?!—!。而相比之下,JEA是基于限制某个用户能运行的Windows Power Shell然后限制用户以管理员的身份连接目标服务器。
这就引出了一个Windows Power Shell问题,即一个标准用户如何在没有Windows Power Shell权限的情况下去执行Windows Power Shell任务呢?理解它工作原理的关键在于,要意识到用户从来不会直接登陆服务器控制台。用户会登录进一个标准的工作站,然后使用JEA PowerShell工具包与被管理的Windows Power Shell服务器建立远程会话。用户登陆的时候会使用自己被限制的Windows Power Shell账号密码,但操作的时候会利用Run As账户来执行任何需要Windows Power Shell更高权限的操作。
从表面上看,如果使用Run As账户这种方式并不会比直接给用户账号授予Windows Power Shell权限更好。但是这两种账号之间有非常重要的区别:一个被赋予Windows Power Shell权限的用户账号基本上算是一个域管理员。使用JEA 的Run As账户是被管理服务器本地的。这个账户不会有域管理权限,这也意味着这个用户不能通过网络进行Windows Power Shell管理员授权的传递。
Just Enough Administration PowerShell工具包不仅仅依赖对用户账号的创新使用来提高安全性,它同时也限制了用户允许执行的Windows Power Shell。这可以保证用户可以运行他工作需要的cmdlets,但是不会有额外的cmdlets。
Just Enough Administration包含了创建一个到被Windows Power Shell管理服务器的远程会话。Windows Power Shell远程会话可以通过会话配置文件或者脚本来进行限制。Just Enough Administration工具包运行允许这些限制以简单的文本文件来配置,这可以控制Windows Power Shell用户被授权运行哪些PowerShell cmdlets。Just Enough Administration工具包同时也可以被设置执行审计的功能。那样的话,如果一个Windows Power Shell用户尝试非授权的行为,这个行为会被阻止并且记录下来以待查看。
Just Enough Administration工具包可以很大程度上地提供企业内部的安全性,Windows Power Shell用户只能执行某些设置好的管理员任务。使用这个工具集的最大缺点是它是面向Windows Power Shell的。Windows Power Shell可以作为一款管理工具来使用,但是使用它需要用户进行一定时间的学习。[8]
Windows Power Shell期望状态配置编辑
Windows Power Shell期望状态配置(DSC)是2013年下半年发布的Windows 8.1和Windows Server 2012 R2最终版本中默认自带的一个功能。Windows Power Shell是一个基于标准Web服务的配置管理系统,Windows Power Shell允许你按照自己的方式对机器进行配置,介绍什么是Windows Power Shell DSC,并将展示它是如何工作的,以及Windows Power Shell可以完成怎样的任务,达到怎样的目标。
许多管理员第一次听说Windows Power Shell工具时就想了解关于Windows Power Shell的一些背景和问题:在试验或真实系统管理解决方案如System Center或者其他第三方工具上使用Windows Power Shell期望状态配置的意义是什么?其有很多优势,但是其中有三点是最为突出的。
Windows Power Shell期望状态配置内置于Windows Server,所以Windows Power Shell没有购买许可和系统管理、配置部署软件管理实例的额外开支。
Windows Power Shell期望状态配置几乎不需要代理,需求只是安装好Windows Power Shell,并且可以通过80或者443端口查询Web服务器来抓取配置信息,这里不需要额外的配置系统管理开销。
Windows Power Shell期望状态配置看起来只是配置文件定义的功能。Windows Power Shell忽略其他设置,使配置负载更加轻巧和加速其他部署,这样Windows Power Shell就可以定义多个配置和堆叠工作负载(一台Web服务器也充当文件服务器,并且Windows Power Shell可以获取没有文件服务器设置覆盖的Web服务器的设置),这类部署是许多系统管理套件无法很容易地应付,甚至完全不能处理。
许多管理员第一次听说Windows Power Shell工具时就想了解关于Windows Power Shell的一些背景和问题:在试验或真实系统管理解决方案如System Center或者其他第三方工具上使用Windows Power Shell期望状态配置的意义是什么?其有很多优势,但是其中有三点是最为突出的。
Windows Power Shell期望状态配置内置于Windows Server,所以Windows Power Shell没有购买许可和系统管理、配置部署软件管理实例的额外开支。
Windows Power Shell期望状态配置几乎不需要代理,需求只是安装好Windows Power Shell,并且可以通过80或者443端口查询Web服务器来抓取配置信息,这里不需要额外的配置系统管理开销。
Windows Power Shell期望状态配置看起来只是配置文件定义的功能。Windows Power Shell忽略其他设置,使配置负载更加轻巧和加速其他部署,这样Windows Power Shell就可以定义多个配置和堆叠工作负载(一台Web服务器也充当文件服务器,并且Windows Power Shell可以获取没有文件服务器设置覆盖的Web服务器的设置),这类部署是许多系统管理套件无法很容易地应付,甚至完全不能处理。
Windows Power Shell的Push模式和Pull模式
Windows Power Shell DSC的基本原则是使用定义所需配置的两种模式,这样管理员既可以自定义地有间隔地使机器从中央存储库获取正确配置信息,也可以将这类Windows Power Shell信息推送回去。
Windows Power Shell的Push模式是一个主动的配置模式运行方式,当你发出的Windows Power Shell命令并且键入的命令带有“-Path”的属性时,Windows Power Shell就会立即触发存在任何位置的基于文件存储的系统配置推送出去。这几乎是一种即时执行“现在就做”的方式来管理你放在中央存储位置的所有配置文件目标和需求,这些文件可以让你计划的目标机器去访问。这个需要你设置经常去触发Windows Power Shell推动,并且默认配置不会自己检测。
Windows Power Shell的Pull模式有一点点被动;Windows Power Shell需要一台服务器同时为配置文件和其它为计算机各方面配置充当中介角色的构件提供清算服务。举个例子,在你编写一个自定义服务提供程序——可以提供使用Windows Power Shell DSC的一段代码——Windows Power Shell可以转换本地自定义业务应用程序的配置文件中的指令。Windows Power Shell的Pull服务器只是一台运行IIS的服务器,而IIS可以发布OData。OData是一种典型、明确定义以及标准支持的界面,通过这个界面Windows Power Shell的Web 服务器可以获取到真正的配置数据。因此,Pull模式是实施Windows Power Shell DSC最常用的方式,也可以用来部署当配置远离期望状态并且超时的情况。Windows Power Shell DSC定期运行,下发正确的配置,执行静默的进程来更改配置为期望状态。
以上的Windows Power Shell配置定义都集成在管理对象文件或者MOF 文件,基本上都是一些文本文件,像一系列的classes,或者是一些Windows Power Shell 配置引擎可以读懂的与Windows操作系统有关的一些元素,抑或是一些可以定义期望配置的classes参数。
Windows Power Shell的MOF文件通常是手动建立一次,然后根据需求进行复制和粘贴。Windows Power Shell对于检测这个配置涉及的安装、移除或者确保某些Windows角色和功能是否已经存在,你可以使用内置命令Get-DscResource来检测。这个Windows Power Shell命令会根据你所以给出的角色或者功能名称,抓取出它们的正确使用语法和其他可用选项。
这些都是Windows Power Shell期望状态配置的基本要素。[9]
Windows Power Shell控制NTFS权限编辑
尽管Windows Power Shell包含一系列本地用来配置存储的cmdlet,但配置NTFS权限的能力明显有限。幸运的是,微软提供了一种利用Windows Power Shell来检索和配置NTFS权限的方法,但是你需要提前下载并安装一个Windows Power Shell专用模块。
所需的模块是文件系统安全Windows Power Shell模块。将文件复制到Windows Power Shell模块文件夹中的NTFSSecurity文件夹下。默认情况下,Windows Power Shell模块文件夹路径
将Windows Power Shell模块复制到相应的文件夹后,可以通过使用下面的Windows Power Shell命令来验证模块的可用性
假设NTFS模块出现在列表里,
记住,除非你已经利用Set-ExecutionPolicy cmdlet更改了服务器的执行策略,否则上面这条Windows Power Shell命令将生成一个错误消息,告诉你系统上的Windows Power Shell脚本是禁止运行的。
输入执行策略后,你就拥有NTFS权限了。
然而,每次需要使用权限的时候都必须输入NTFSSecurity模块。
假设我在服务器上创建了文件夹C:\Data 。接着,假如想查看这个Windows Power Shell文件夹的访问控制列表条目,
上面命令列出每个访问文件夹的账户/安全组、访问权限、应用权限、权限类型以及IsInherited和InheritedFrom标志(见图1)。
所需的模块是文件系统安全Windows Power Shell模块。将文件复制到Windows Power Shell模块文件夹中的NTFSSecurity文件夹下。默认情况下,Windows Power Shell模块文件夹路径
将Windows Power Shell模块复制到相应的文件夹后,可以通过使用下面的Windows Power Shell命令来验证模块的可用性
假设NTFS模块出现在列表里,
记住,除非你已经利用Set-ExecutionPolicy cmdlet更改了服务器的执行策略,否则上面这条Windows Power Shell命令将生成一个错误消息,告诉你系统上的Windows Power Shell脚本是禁止运行的。
输入执行策略后,你就拥有NTFS权限了。
然而,每次需要使用权限的时候都必须输入NTFSSecurity模块。
假设我在服务器上创建了文件夹C:\Data 。接着,假如想查看这个Windows Power Shell文件夹的访问控制列表条目,
上面命令列出每个访问文件夹的账户/安全组、访问权限、应用权限、权限类型以及IsInherited和InheritedFrom标志(见图1)。
图1. 通过Windows Power Shell查看NTFS权限
授予Windows Power Shell文件夹访问权限与查看现有权限一样简单。你需要使用Add-NTFSAccess cmdlet。另外还需要指定路径、账户和访问权限。这里使用例子说明。假设“Everyone”都能安全访问到C:\Data文件夹。
现在,我已经添加了Windows Power Shell权限,让每个人都能访问C:\Data,并且利用Get-NTFSAccess cmdlet验证权限(图2)。
图2. Windows Power Shell任何人可访问
即使能够将Windows Power Shell权限授权给所有人,通常来说必须确认Windows Power Shell账户位置(图2)。例如,一些已有的权限位置为BUILTIN或NT AUTHORITY。在实际操作中,通常会指定一个Windows Power Shell连带用户组名或用户名的域名。例如,如果你想授权访问Contoso域中的Finance组,那么账户名为Contoso\Finance。
Windows Power Shell删除NTFS权限有点棘手。接着上面的例子,你必须确认Windows Power Shell路径、账户名称以及打算删除的Windows Power Shell权限。
该Windows Power Shell命令有点棘手的原因在于,你无法删除Windows Power Shell继承权限。而且,删除的Windows Power Shell权限必须与目前分配给该帐户的Windows Power Shell权限准确匹配。如果匹配失误,则命令无效。
因为有时难以完全精准匹配权限,所以使用几个命令一起删除权限会更加方便。假如你想删除C:\Data文件夹Everyone的所有权限,不必手工匹配权限,你可以使用Windows Power Shell读取该权限然后进行删除该。
如果你想从整个Windows Power Shell文件夹树中删除权限,可以递归使用该命令(图3)。
PowerShell的作用编辑
PowerShell中包含了大量的新特性和新功能,PowerShell提升了整体的用户体验。虽然PowerShell中一些功能只能供硬核PowerShell开发人员使用,但PowerShell其他新功能和特性具有广泛的适用性。
PowerShell另一个改善的功能是期望状态配置。对于不熟悉PowerShell期望状态配置的用户来说,PowerShell改善后的功能允许管理员对比Windows服务器的期望状态,如果PowerShell服务器出现问题并偏离了理想的配置,利于管理员及时采取修正措施。
PowerShell节流阀限制
PowerShell新版中的期望状态配置功能语法与以前版本相同,但有一点差异。微软已经引入了一个名为–ThrottleLimit的命令行开关。PowerShell命令行开关后跟随期望状态配置操作所需的最大数量。
PowerShell细微变化
PowerShell中复制粘贴存在的一个大问题是,如果你选择多行代码复制,PowerShell会单独复制每行,PowerShell不会复制整个代码块。例如,如果你复制一条长达四行的命令,然后粘贴到PowerShell界面,PowerShell会在每行之间插入换行符,这会导致错误信息。
PowerShell最新功能编辑
过去的几个版本的Windows Server里,微软加大了在PowerShell工具上的研发投入,使得其能够灵活可用。其中值得称道的一点是在Windows Server 2008 R2和Windows Server 2012里,可用通过PowerShell创建能用于裸机恢复的备份。在本文中,我们将讨论如何操作。
虽然现在通过PowerShell进行裸机恢复的备份并不是必须的,但是微软声称PowerShell是微软推荐的Windows服务器管理接口,传统的基于图形的管理方式终将成为过去。因此,系统管理员们需要掌握PowerShell以免被时代所淘汰。
对于不同的应用所使用的恢复操作也不尽相同。本文主要的对象是Windows服务器备份应用。当然也会有其它的一些备份厂商们支持命令行的备份操作方式,但不同的厂商所提供的命令也是不同的。
因此,需要在Windows Server上做一些准备工作好让Windows服务器备份命令安装到PowerShell里:
在Windows Server 2012版本中,将会自动加载所必需的的PowerShell模块,然而如果使用的是Windows Server 2008 R2,那么则需要运行All Modules命令载入所需的模块组件。[12]
免费的PowerShell资源与工具编辑
PowerGUI
PowerGUI,由Quest Software公司研发(现在是戴尔的一部分),基本上是一个GUI,开发PowerShell脚本时,围绕PowerShell提供更多的可见性以及附加功能。PowerGUI无疑为我们提供了一些重要的特性,可以帮助我们创建和编辑PowerShell脚本。
PowerGUI中一个有用的部分是代码片段。代码片段是可重复利用的代码块,编写代码时很容易将它们插入脚本。试想一下如下的场景,你会发现自己在脚本上重复输入类似的代码。例如,声明函数是开发代码片段的一个主要目标。
下一个有用的部分PowerGUI称之为变量探针。变量探针允许在脚本中扩展和审视你所使用的局部变量。想知道哪个属性或方法需要使用特定对象?动态变量探针允许你查看这些属性,连同脚本中同一界面相应的值。变量探针可以真正地节省时间。
接下来我们看看升级包扩展。这些升级包本质上说是给你一个表示各自应用程序的图形,可以只用鼠标逐字地编写脚本。例如,使用虚拟化升级包,你可以在一个树类型接口浏览虚拟机和主机,并生成不同的脚本报告以及管理你的环境。除了vSphere之外,你还可以找到集中在Active Directory、SQL、Sharepoint的扩展。
最后,还有选项卡完成和语法高亮显示。相比其他,这虽然不是一个庞大的功能,但很受开发人员欢迎。除了命令中的显示卡完成,通过自动显示选项卡完成呈现给我们需要寻找的参数,一切都变得简单。在高亮显示方面,PowerGUI强调类似的语法,使脚本更容易阅读并且能更容易地识别不同区域。
管理脚本编辑器
大多数PowerShell脚本编写仅仅基于文本并在PowerShell控制台执行。即便如此,有时我希望可以在一些脚本中包装一个GUI,与他人共享脚本,帮助那些对“命令行”不太精通的人。
在PowerShell上创建GUI不是为了意志薄弱的人——通常它产生数百行代码,需要在屏幕上负责控制的地方指定值x和y轴的值。之后,你还要完成在控制中添加事件处理程序和操作的艰巨任务。值得庆幸的是,有一个应用程序可以为我们做这一切,在一个很好的拖放界面。该应用程序被称为管理脚本编辑器(ASE)。
ASE的历史肯定是独一无二的。它曾经是一个付费的、完全支持脚本编辑的应用程序,然而,当其他编辑器上市,ASE决定关闭商店并免费发布最终版本。ASE和PowerGUI一样,也是一个脚本编辑器和开发环境,在PowerShell脚本中创建GUI包装和形式时,我倾向于仅仅使用它。ASE有一个独特的拖放界面,允许你轻松地设计包含不同控件的形式,比如文本框、下拉组合框、日历日期选择器等。除此之外,它还创建了点击更改事件的功能按钮和输入。
PowerCLI社区
对于所有PowerCLI网站来说,虚拟化网站上的PowerCLI社区网站资源最丰富。在这里你可以找到所有PowerCLI文档的链接,可以下载并在论坛上提问。从我的经验可以告诉你,在这个论坛上提问,从来没有置之不理的情况。当天得到问题回复是很常见的。除了破坏或修复,以及提问信息,论坛还包含一个文档部分,包括100种以上不同的脚本,虚拟化员工以及合作伙伴和客户都曾参与编写,这些脚本可供大家下载。在PowerCLI社区,你应该可以找到任何需要的东西。
Project Onyx
在PowerCLI上执行一个特定任务,需要想出一些合适的语法很困难吗?你知道如何完成vSphere客户机的任务吗?如果是这样,Onyx项目可以帮助你。Onyx项目在虚拟化中很受欢迎,基本上充当vSphere客户机和vCenter服务器之间的代理服务器。运行和安装Onyx很简单,可以在vSphere客户机上执行任务。Onyx会将所有已经完成的操作转化为vCO Javascript或虚拟化 PowerCLI/PowerShell语法。在这里你可以简单复制代码、修改和使用。Onyx项目很棒,当你试图弄清楚如何在PowerCLI完成特定的vSphere任务但却无能为力时,它可以帮你一把。
无论是谷歌还是其他你钟情的搜索引擎,它都可以提供帮助。尽管谷歌不是实际的PowerCLI资源,索引器和网关可以帮助你找到数以百万计的脚本,这些脚本在互联网论坛、博客,、项目和网站随处可见。PowerShell和PowerCLI的好处是简单易读,进而使他们容易理解,但更重要的是具有可编辑性。[13]
Windows Power Shell自动化服务器编辑
Windows Power Shell带来了很多有助于管理员的新功能,最显著的是增强了自动化功能。让我们一起来看看Windows Power Shell是如何通过自动化让Windows服务器管理员的生活变得简单的。[14]
没有评论:
发表评论