SCOM PowerShell 命令使用指南 - 11 (Misc.)

142536a

　　在说完并不让人觉得轻松的名词部分是Override的命令之后，这周要介绍的几个名词都和系统管理员的日常工作有很大关系，同时也是SCOM中比较基础的几个概念。
　　首当其冲的是名词部分是Alert的命令。我们使用SCOM的目的就是当被监视的系统出现故障时，SCOM能及时发出警报。在SCOM的PowerShell控制台中可以使用Get-Alert来获得所有报警信息，这里需要注意的是Get-Alert在不带参数的情况下会返回所有Alert，因此如果我们想要看到和图形界面一致的警报数量时，需要使用以下命令：
　　Get-Alert -Criteria "ResolutionState=0" | FT Name,ResolutionState –A

　　这里ResolutionState的数字0代表New状态，当然这个状态是可以通过图形界面来进行调整的。

　　现在假设我们已经解决完警报中提示的问题后，接下来就可以使用Resolve-Alert来关闭警报。而如果需要关闭特定的活动警报则可以在Get-Alert的搜索条件中指定Name和ResolutionState的值。示例如下：
　　>Get-Alert -Criteria "Name='Could not determine the FSMO role holder.' And ResolutionState=0" | Resolve-Alert -Comment "Resolved Alert" –Verbose

　　接下来的一个问题情境就是，当一个问题反复出现后，系统管理员希望了解问题出现的频率及时间。如果上级需要了解系统管理员对问题的处理时间的话，那我们也要想办法提交。每次通过图形界面的HealthExplorer去查警报的历史记录的话，其实是非常耗时以及单调的工作。我们完全可以使用Get-AlertHistory命令来获得相关信息。下面就是一个示例命令：
　　Get-Alert -Criteria "Name='Could not determine the FSMO role holder.'" | Get-AlertHistory | FT ResolutionState,Time*

　　由于演示环境中的ResolutionState只定义了两种状态，其实完全可以通过之前的图形界面来定义多种状态，比如10 - Tier 1 Resolving, 30 - Tier 2 Resolving, 40 - Tier 2 Resolved等等，可以帮助我们分析问题的解决时间，团队之间的沟通效率等等。
　　接下来的两个命令则和我们之前提到的Connected Management Group有关，也就是在管理组之间转发警报。首先是Get-AlertDestination，该命令主要使用获得警报是通过哪个Connector进行转发的。

　　我们也可以使用Set-AlertDestination来设置Alert的转发目的地，下面的演示中使用的是SCOM自带的Connector，如果各位在环境中配置了其他Connector，那也可以将Alert转发到其他Connector。

　　接下来，我们要关注到到的是名词部分是Task的命令。SCOM中的Task的种类可以说是非常丰富，而图形界面中的Task Status节点，则为我们提供了观察Task执行状态的一个非常好的视图。而在命令行下，Get-Task也为我们实现了相同的功能。默认情况下Get-Task不指定任何参数就能获得相关的任务信息，假设我们要获得特定Task的信息，那么同样可以使用Where-Object来对默认的输出进行过滤，以下便是一个例子：

　　当然，这里仅仅只是根据我自己测试环境的情况所举的一个例子，各位可以根据自己的情况来指定，总的来说使用Where-Object来进行筛选并不是很复杂。接下来看看如何使用Start-Task启动一项Task。这里以自定义的任务GetVersion来说明。首先我们可以在Authoring界面中自定义任务GetVersion。接着使用Get-Task找到GetVersion并将找到的对象存入变量$task。随后需要准备Start-Task所需的另一项参数-TargetMonitoringObject, 可以使用Get-MonitoringObject来获得。最终在PowerShell下使用Start-Task的步骤如下：
　　$task = Get-Task -Criteria "DisplayName='GetVersion'"
　　$mc = Get-MonitoringClass -Name Microsoft.Windows.Computer
　　$mo = Get-MonitoringObject -MonitoringClass $mc | ?{$_.DisplayName -match "CNSHSQLSVR01"}
　　Start-Task -Task $task -TargetMonitoringObject $mo
　　命令的运行结果如下：

　　当然，刚才命令的运行结果也可以用Get-TaskResult来提取，使用起来也很简单。先将刚才的运行结果保存到变量$taskResult中，然后使用Get-TaskResult并指定ID参数即可：Get-TaskResult -Id $taskResult.Id。
　　接下来我们来看一下名词部分是MaintenanceWindow的命令。首先维护窗口这个概念对系统工程师来说并不陌生，为了满足SLA中所规定的服务运行时间，我们必须在指定的时间段内完成系统的维护工作。而在维护窗口内由SCOM所产生的各种警报也应被视为正常现象。当然更好的方法是告诉SCOM，在维护窗口内暂停产生警报。在一个大型环境中，设置维护窗口也是需要一定技巧的，比如先设置前端网页服务器，在设置后端数据库服务器。虽然图形界面也能进行批量设置，但是可能不太满足我们的需要，因此我们可以使用名词部分是MaintenanceWindow的命令来完成设置维护窗口的任务。
　　首先我们需要使用New-MaintenanceWindow来设置一个维护窗口。维护窗口有四个组成要素，开始时间，结束时间，维护原因，以及注释。具体的命令如下：
　　[DateTime] $starttime = Get-Date
　　$starttime = $starttime.ToUniversalTime()
　　[DateTime] $endtime= "07/09/2011 15:30:00"
　　$endtime = $endtime.ToUniversalTime()
　　$mw = new-maintenancewindow -starttime $starttime -endtime $endtime -Reason PlannedOther -comment "Security Patch of July" -MonitoringObject $mo
　　这里需要注意的是Reason并不是随意指定的字符串，而是一些特定值，各位可以查看New-MaintenanceWindow的帮助信息来查看可用值。而$mo则是一组特定的MonitoringObject对象，获得该对象的技巧已经在上次阐述过了，各位不妨回过头去再看看。命令执行完成之后，维护窗口便被打开了，我们可以使用Get-MaintenaceWindow来查看特定对象的维护窗口：Get-MaintenanceWindow -MonitoringObject $mo

　　接下来，如果我们需要调整维护窗口的时间的话，则可以使用Set-MaintenanceWindow来完成，具体命令如下：
　　Set-MaintenanceWindow -MonitoringObject $mo -EndTime $(Get-Date)
　　接着再来看下SCOM中的另一项重要功能，警报订阅。警报订阅也是大家很容易理解的一项功能，主要帮助我们通过各种渠道来了解SCOM监视的各种系统的状态，从而防止监控空白。
　　在SCOM为我们提供的命令中警报订阅这项功能主要通过名词部分包含Notification的命令来实现。接下来，还是先来看下如何使用Get-NotificationSubscription来获得警报订阅列表，该命令可以不加参数运行，也可以通过指定Id参数来获得特定的订阅的警报。当然我相信绝大多数朋友肯定会先不加参数执行一下命令，因为代表Id的GUID并不是那么好记，这一点我们可以从命令的运行结果中就可以知道：

　　接下来，我们可以将Get-NotificationSubscription和Enable-NotificationSubscription及Disable-NotificationSubscription命令来启用或者禁用警报订阅。

　　最后来看下剩下的三个命令：Get-NotificationAction, Get-NotificationEndpoint以及Get-NotificationRecipient。这三个命令很简单，第一个命令管理界面中的Subscription节点，第二个命令对应Channels节点，第三个命令对应Subscribers节点。三个命令的主要作用就是列出这三个节点下的对象。好吧，看到这里大家肯定注意到了，这些名词没有对应的动词Set来配合，相信大家会有点失望。这里我就试试看能不能通过PowerShell新建一个NotificationRecipient来说明。
　　首先我们来看下Get-NotificationRecipient返回哪些信息：

　　接着给出我查阅SDK和搜索之后得到结果：
　　$notificationRecipient = New-Object Microsoft.EnterpriseManagement.Administration.NotificationRecipient "CORP\Anna"
　　$notificationRecipientDevice = New-Object Microsoft.EnterpriseManagement.Administration.NotificationRecipientDevice "Smtp","anna@nwtrader.com"
　　$notificationRecipientDevice.Name = "anna@nwtrader.com"
　　$notificationRecipient.Devices.Add($notificationRecipientDevice)
　　$(Get-ManagementGroupConnection).ManagementGroup.InsertNotificationRecipient($notificationRecipient)
　　首先利用New-Object新建NotificationRecipient对象，并传递“Corp\Anna”给构造器作为Name参数，接着新建NotificationRecipientDevice对象，这里对象的设备是邮件，因此构造器第一个参数Protocol是Smtp，第二个参数是邮件地址。接着将得到的notificationRecipientDevice对象通过Add方法添加到$notificationRecipient.Devices属性。这里使用了Add方法，是需要注意到的地方。最后我们调用ManagementGroup的InsertNotificationRecipient方法递交修改。随后我们就可以用Get-NotificationRecipient查看下修改有没有成功：

　　最后，我们来看看SCOM PowerShell命令中的最后一部分。首先来看看名词部分包含User的命令。命令一共两个，Get-UserRole和Add-UserToUserRole。这两个命令对应图形界面中Administration中Security节点下的User Roles节点。
　　首先我们来看看Get-UserRole的运行结果。大家可以看到命令的使用非常简单，命令会显示SCOM安装完毕后内置的一些安全角色。接下来假设我们要将一个安全主体添加到安全角色中，比如将用户Anna添加到Operations Manager Operators中，那么就应当使用Add-UserToUserRole命令。

　　命令的使用其实非常简单，第一步当然是得到需要操作的UserRole对象，第二步通过管道将用户账号添加到UserRole中的。因此命令如下：
　　Get-UserRole | ?{$_.DisplayName -eq "Operations Manager Operators"} | Add-UserToUserRole -User "corp\anna"
　　在命令的返回对象中，我们也可以看到刚才的用户账号已经被成功的添加到Operations Manager Operators这个Role中。

　　而接下来要介绍的命令则是Get-RunAsAccount，命令的作用也非常简单，返回Administration下Run As Configuration下的Accounts信息。当然大家也看到了RunAsAccount没有动词Set或者Add与之搭配，这也不难理解，可能产品组当时做决策的时候考虑到这一块用PowerShell进行大批量操作的情况比较小，因此没有去实现。这里我也不再展开了，有兴趣的朋友不妨可以去SDK中找找有用的信息。
　　而Get-Event和Get-Diagnostic则分别用来显示MonitoringObject中底层对象的一些信息，这连个对象的也没提供其它动词与之搭配，因此我们也只能看看作罢：

　　至此，所有SCOM 2007中的PowerShell命令就介绍完毕了，总的来说有喜有忧吧，好在SCOM 2012的测试版已经发布了，PowerShell这一块的命令有所改进，各位可以去看下产品组给我们带来了哪些新功能。
　　已发表 2011年8月23日 22:54 作者 ghjconan
　　归档在：SCOM, PowerShell, OpsMgr