• 아티클

System Center

System Center Operations Manager의 Windows PowerShell

Marco Shaw

 

한 눈에 보기:

  • OpsMgr 명령 셸
  • OpsMgr Monitoring 공급자
  • 일반 관리 작업 자동화
  • 몇 가지 실제 Windows PowerShell 예제

목차

Operations Manager 명령 셸
OpsMgr Monitoring 공급자
일반 작업 자동화
실제 사례
요약

System Center Operations Manager 2007(OpsMgr)을 통해 관리자들은 작업 자동화를 위한 강력하고 새로운 스크립팅 언어인 Windows PowerShell에 액세스할 수 있게 되었습니다. 2006년 11월에 일반에 공개된 Windows PowerShell은 지금까지 2백만 회 이상 다운로드되었습니다.

여기서는 Windows PowerShell®을 소개하고 Operations Manager에 어떻게 적용되는지 설명합니다. 또한 Windows PowerShell을 통해 더욱 쉽고 자동화된 방법으로 수행할 수 있는 몇 가지 일반적인 작업을 설명하고, 유용한 스크립트와 설명을 제공하는 웹 사이트를 안내합니다. 현재 Windows PowerShell을 사용하는 많은 전문가들의 유용한 정보 및 블로그 게시물도 소개합니다.

Microsoft는 CTP(Community Technology Preview) 버전의 Windows PowerShell 2.0을 발표하기 시작했지만 이러한 버전은 프로덕션 환경에서 사용할 준비가 되지 않았고 OpsMgr에서 테스트되지 않았으므로 프로덕션 시스템에 설치하면 안 됩니다.

Operations Manager 명령 셸

OpsMgr에서는 콘솔 파일을 로드하고 OpsMgr cmdlet, 함수 및 기본 연결로 환경을 초기화하는 스크립트를 로드한다는 것을 제외하고 기본 Windows PowerShell 환경과 유사한 명령 셸을 통해 Windows PowerShell에 액세스합니다.

명령 셸은 OpsMgr 시작 메뉴의 아이콘으로 시작하거나 OpsMgr UI 콘솔에서 컴퓨터 이름을 마우스 오른쪽 단추로 클릭하여 시작할 수 있습니다(그림 1 참조). 그러면 바로 OpsMgr Monitoring 드라이브 경로(곧 설명 예정)에 있게 됩니다.

fig01.gif

그림 1 OpsMgr UI에서 명령 셸 열기(크게 보려면 이미지 클릭)

Windows PowerShell은 OpsMgr SDK를 통해 OpsMgr와 상호 작용합니다. 관리자에게는 다행스럽게도 일반적으로 자동화하거나 명령줄에서 완료하기를 원하는 많은 작업을 위한 cmdlet이 이미 제공되었습니다. 특정 작업에 대한 cmdlet이 없다면 Windows PowerShell을 사용하여 SDK와 상호 작용할 수 있습니다.

Operations Manager 명령 셸에서 제공되는 명령은 Windows PowerShell에서 로드되고 OpsMgr 관리용 cmdlet을 포함하는 DLL인 스냅인에 포함되어 있습니다. 스냅인에는 OperationsManagerMonitoring Windows PowerShell 공급자도 포함됩니다. 간단히 Monitoring 공급자라고 하는 이 도구를 통해 파일 시스템을 탐색하는 것처럼 연결, 그룹 및 모니터링 개체를 탐색할 수 있습니다.

OpsMgr의 모든 cmdlet 목록은 그림 2와 같이 Get-OperationsManagerCommand cmdlet을 사용하여 볼 수 있습니다. 첫 번째 버전에서 이 명령은 탭 완성을 지원하지 않는 함수였으며 SP1에서 cmdlet이 되었습니다. Operations Manager의 최초 릴리스에는 74개의 cmdlet이 포함되어 있었고, OpsMgr SP1에는 87개의 cmdlet이 포함됩니다.

fig02.gif

그림 2 OpsMgr cmdlet 목록 보기(크게 보려면 이미지 클릭)

OpsMgr Monitoring 공급자

cmdlet Set-Location 또는 별칭 cd를 사용하여 그룹 및 컴퓨터의 레이아웃을 탐색할 수 있습니다. 기본 Monitoringdrive에 대한 기준 레이아웃은 다음과 유사합니다.

Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)

여기에서 특정 개체로 이동할 수 있습니다. 이 문서에서는 하나의 관리 서버만 있는 단순한 환경을 대상으로 합니다. 관리 그룹에 설치된 첫 번째 관리 서버를 루트 관리 서버(RMS)라고 합니다.

명령 셸이 시작되면 Monitoring이라는 드라이브가 만들어지고, 드라이브가 OperationsManagerMonitoring 공급자의 루트에 매핑되며, 마지막으로 현재 위치나 경로가 Monitoring 드라이브의 루트로 설정됩니다. 그런 다음 명령 셸은 연결할 기본 RMS의 이름을 레지스트리에서 검색합니다. RMS 연결에 성공하면 그림 3과 같이 현재 위치나 경로가 연결 이름 또는 RMS로 설정됩니다.

fig03.gif

그림 3 RMS로 설정된 명령 셸 위치(크게 보려면 이미지 클릭)

일반 작업 자동화

Windows PowerShell에서 몇 가지 가장 일반적인 관리 작업을 어떻게 처리할 수 있는지 살펴보겠습니다.

유지 관리 모드 제어 어떠한 작업을 대상으로 하건 대개 발생해야 하는 날짜와 시간을 지정하게 됩니다. Get-Date cmdlet을 사용하여 이 작업을 얼마나 쉽게 수행할 수 있는지 살펴보겠습니다. 그림 4에 몇 가지 예가 표시되어 있습니다.

fig04.gif

그림 4 Get-Date cmdlet 사용(크게 보려면 이미지 클릭)

보시는 바와 같이 현재 시간을 나타내는 개체가 포함된 $date 변수를 만들었습니다. 그런 다음 개체에서 지원하는 몇 가지 문서화된 방법을 사용하여 날짜와 시간을 5분 후, 5시간 후로 쉽게 설정할 수 있습니다. 과거의 값으로 설정하려면 간단히 (5) 대신 (-5)를 사용하면 됩니다.

컴퓨터에서 발생하는 모든 경고를 차단해야 하는 경우 유지 관리 모드를 사용할 수 있습니다. OpsMgr 2007에서는 전체 컴퓨터나 그룹 대신 Windows® 서비스 또는 특정 데이터베이스를 유지 관리 모드로 전환할 수 있습니다. 특별히 유지 관리 모드 작업을 대상으로 하는 cmdlet에는 Get-MaintenanceWindow, New-MaintenanceWindow 및 Set-MaintenanceWindow의 세 가지가 있습니다.

명령 셸 내에서 컴퓨터를 유지 관리 모드로 전환하려면 그림 5와 같이 Monitoring 공급자를 사용하여 원하는 컴퓨터나 모니터링 개체로 이동하고 New-MaintenanceWindow cmdlet을 호출합니다. 보시는 바와 같이 이 작업은 Denver.contoso.com이라는 컴퓨터를 유지 관리 모드로 전환합니다. 또한 유지 관리 기간이 즉시 시작되고, 정확히 1시간 후에 종료되도록 정의했습니다. 이 방법을 사용하여 컴퓨터를 유지 관리 모드로 전환할 경우 이 개체에 대한 HealthService 및 HealthServiceWatcher 인스턴스가 아직 사용되므로 일부 경고는 중지되지 않습니다.

fig05.gif

그림 5 New-MaintenanceWindow cmdlet 사용(크게 보려면 이미지 클릭)

Microsoft OpsMgr 팀의 Boris Yanushpolsky 프로그램 관리자는 컴퓨터를 참조하는 모든 개체를 유지 관리 모드로 설정하는 데 사용할 수 있는 매우 간편한 Windows PowerShell 코드를 제공하고, 스크립트를 만든 경우 이 코드를 사용하는 방법도 설명했습니다. 이에 대한 자세한 내용을 보려면 그의 블로그 blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx를 방문하십시오.

때때로 유지 관리 모드가 되면 안 되는 개체인지 확인해야 할 수 있습니다. 하지만 이것을 알아내기 위해 모든 개체를 일일이 조사해야 한다면 큰 고역이 아닐 수 없습니다. 다행히 Boris Yanushpolsky는 OpsMgr SDK를 사용하는 Windows PowerShell 스크립트로 다시 도움을 주었습니다. 그의 블로그 게시물(blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx)에서 바로 코드를 복사하여 명령 셸 창에 붙여 넣으면 유지 관리 모드의 모든 개체 목록을 확인할 수 있습니다.

개체가 유지 관리 모드인 경우 원래 지정한 종료 시간 전에 유지 관리 기간을 끝낼 수 있습니다. Windows PowerShell에 익숙하다면 stop 또는 remove 동사가 있는 cmdlet을 기대하겠지만 실제로는 그림 6과 같이 Set-MaintenanceWindow를 사용해야 합니다.

fig06.gif

그림 6 Set-MaintenanceWindow를 사용하여 종료 시간 변경(크게 보려면 이미지 클릭)

에이전트 관리 관리자는 에이전트로 작업하는 경우가 많으며, 다양한 에이전트 관련 작업을 대상으로 하는 6개의 cmdlet과 1개의 함수(현재 릴리스 기준)가 있습니다. 이 목록은 다음 명령을 사용하여 확인할 수 있습니다.

Get-Command *-agent*

SP1 릴리스에서는 Install-AgentByName이 함수 대신 cmdlet으로 패키지화되어 있습니다. Install-AgentByName cmdlet은 지원 및 일관성을 위해 더 좋은 기준을 제공하므로 이것을 사용하는 것이 좋습니다.

명령 셸에 포함되어 있는 도움말에서는 Install-Agent 및 Uninstall-Agent cmdlet을 사용하는 몇 가지 좋은 예를 제공합니다. Microsoft OpsMgr 팀의 Roger Sprague 상임 소프트웨어 설계 엔지니어는 그림 7에 표시되어 있는 것과 같이 그의 블로그에서 대체 방법을 게시했습니다(원본 게시물은 blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx 참조).

이 스크립트는 OpsMgr RTM에서 제대로 작동하지만(Monitoring 공급자의 루트, 이 문서의 경우 monitoring:\oxford.contoso.com에 있어야 함), OpsMgr SP1에서는 제대로 작동하지 않습니다. OpsMgr SP1에서 작동하도록 하려면 그림 7의 첫 번째 명령을 다음과 같이 변경해야 합니다.

 $managementServer = Get-RootManagementServer

그림 7 에이전트 설치

# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects

이제 모니터링되어야 하는 원격 시스템에 에이전트가 설치되었지만, 완전하게 모니터링하려면 먼저 관리 서버가 실제로 새 에이전트를 승인하도록 하는 마지막 단계가 남아 있습니다. 여기서 추가 작업을 수행하지 않을 경우 모니터링 서버가 모니터링을 위해 새 에이전트를 자동으로 승인합니다. 그러나 이 승인 프로세스도 Get-AgentPendingAction cmdlet을 사용하여 빠르게 수행할 수 있습니다. 다음 한 줄을 사용하여 에이전트 승인 프로세스를 빠르게 처리할 수 있습니다.

Get-AgentPendingAction | Where Object {$_.AgentName –like 
'computer*'} | Approve-AgentPendingAction

이 작업이 아직 보류 상태인 경우 이것을 Approve-AgentPendingAction 대신 Reject-AgentPendingAction에 연결하면 OpsMgr 서버에서 이 에이전트를 승인하는 것을 차단할 수 있습니다. 보류 상태가 아니면 대신 Uninstall-Agent cmdlet을 사용합니다.

앞에서 언급한 대로 명령줄에서 에이전트가 설치되어야 하는 컴퓨터를 직접 지정하기 위해 Install-AgentByName을 사용할 수도 있습니다.

관리 팩 작업 다양한 관리 팩 작업을 처리할 수 있도록 4개의 cmdlet이 제공됩니다. 이 목록은 다음을 사용하여 확인할 수 있습니다.

Get-Command –noun ManagementPack

다음의 간단한 명령은 현재 설치된 관리 팩과 버전 번호를 제공합니다.

Get-ManagementPack | Format-Table –autosize

이제 명령 셸에서 다음 설치 관리자를 사용하여 두 가지 일반적인 관리 팩을 설치해 보겠습니다.

  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.

여기서는 명령 셸을 통해 일반적인 작업을 더 쉽게 수행할 수 있음을 보여 주는 것이 목적이므로 가능한 한 가장 적은 수의 명령을 사용하여 시도해 보겠습니다(그림 8 참조). quiet 플래그를 설치 관리자(.msi 파일)에 전달하도록 이 설치 절차를 변경할 수도 있지만, 파일이 수동으로 추출되는 위치를 선택했습니다.

fig08.gif

그림 8 관리 팩 설치(크게 보려면 이미지 클릭)

이제 공용 라이브러리를 설치해야 하므로 다음과 같이 수행할 수 있습니다.

Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

그런 다음 기타 필수 관리 팩을 설치합니다.

Get-ChildItem –Path C:\MPs –filter *200?.mp | 
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

그림 9에 표시된 것과 같이 명령 셸 도움말은 Export-ManagementPack cmdlet을 사용하여 봉인되지 않은 관리 팩을 내보내는 좋은 예를 제공합니다. 모든 관리 팩을 내보내려면 다음 줄을 변경합니다.

 $mps=Get-ManagementPack | 
Where-Object {$_.Sealed –eq $false} 

 $mps=Get-ManagementPack

fig09.gif

그림 9 관리 팩 내보내기(크게 보려면 이미지 클릭)

사용자 역할 조작 Get-UserRole cmdlet은 사용자 관리를 위한 몇 가지 기능을 제공하지만, 이상하게도 보완하는 Set cmdlet이 제공되지 않고 일반적으로 편집이나 업데이트에 사용하지 않습니다(Windows PowerShell SDK 설명서에 따라). 그림 10에 표시된 것과 같이 먼저 현재 사용자 역할 목록을 확인한 다음 사용자를 Read-Only Operators 그룹에 추가합니다(그림 11 참조).

fig10.gif

그림 10 사용자 역할 표시(크게 보려면 이미지 클릭)

fig11.gif

그림 11 사용자 추가(크게 보려면 이미지 클릭)

ACS(Audit Collection Services) 사용 ACS는 간단히 말해서 보안 감사 정보를 다루기 위한 중앙 집중식 방법을 제공하는 Operations Manager 2007의 새로운 선택적 기능입니다. ACS는 기본적으로 사용되지 않으며, 대개 OpsMgr 배포의 이후 단계에서 나중에 구성됩니다.

ACS에 대해 많은 수의 에이전트를 사용해야 하는 경우 Windows PowerShell을 통해 설정을 자동화할 수 있습니다. OpsMgr 베타 버전에서 Microsoft는 모든 에이전트에서 ACS를 사용할 수 있는 스크립트를 제공했습니다. SystemCenterForum.org의 기고가이며 블로거인 Neale Browne은 이것을 한 수준 높이고 추가 매개 변수에 대한 지원 기능을 추가했습니다.

SystemCenterForum.org 사이트(Microsoft® System Center 솔루션을 제공하는 커뮤니티 사이트)에서는 ACS의 설정을 자동화하는 데 사용할 수 있는 두 가지 서로 다른 Windows PowerShell 스크립트를 만들었습니다. 특정 그룹의 모든 에이전트를 설정하려면 systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip을 사용합니다. 모니터링되는 모든 에이전트를 설정하려면 systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip을 다운로드합니다.

에이전트 프록시 사용 OpsMgr 환경에는 에이전트 없이 모니터링되는 장치가 포함될 수 있습니다. 이러한 장치는 관리 서버에 지정하거나 원격 모니터링을 제공하는 에이전트 관리 장치에 지정해야 합니다. Windows PowerShell 스크립트를 사용하여 많은 수의 에이전트를 구성하는 것에 대한 자세한 내용은 systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell에서 찾을 수 있습니다. 업데이트된 스크립트 버전은 systemcenterforum.org/wp-content/uploads/Set­AgentProxyBulk_FQDN.zip에서 제공됩니다.

특정 관리 팩에서 에이전트가 프록시로 작동하도록 설정해야 하는 다른 조건도 있습니다. 자세한 내용은 관리 팩 설명서를 참조하십시오.

실제 사례

여기에는 Windows PowerShell을 사용하여 자동화할 수 있는 방법을 보여 주는 몇 가지 실례를 설명합니다.

경고 해결 특정 컴퓨터에 대한 여러 가지 경고를 삭제해야 했던 적이 있었습니까? 응용 프로그램에 무엇인가 잘못되었거나 경고가 제대로 해결되지 않았을 수 있습니다. 다음은 해결 상태가 0인 모든 경고를 해결하는 한 줄 명령입니다.

Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null

다음 예는 위의 명령과 동일한 기능을 수행하지만, 해결되지 않은 더 많은 경고가 있는 대규모 환경에서 더욱 빠르게 실행됩니다.

Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null

이렇게 성능 차이가 나는 이유는 기준 매개 변수를 사용할 경우 전달되는 값이 SQL Server® 데이터베이스에 직접 제공되고 관련 데이터만 반환되기 때문입니다. 결과적으로 다시 Windows PowerShell 콘솔로 전달되어야 하는 개체가 줄어듭니다.

이제 한 컴퓨터에 대해 해결되지 않은 모든 경고를 빠르게 제거할 수 있는 방법을 알게 되었습니다. 필요에 따라 이것을 자동으로 실행되도록 설정할 수 있습니다.

마지막으로 다음은 특정 일의 모든 경고를 볼 수 있는 빠른 명령입니다.

Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''

날짜 값을 매우 쉽게 변경할 수 있고, 출력을 Resolve-Alert cmdlet에 연결할 수 있습니다.

테스트 경고 때때로 Windows 이벤트 뷰어에서 특정 이벤트를 모니터하고 테스트해야 할 수 있습니다. 다음 두 줄을 사용하여 빠른 이벤트 로그 항목을 만들 수 있습니다.

 $api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")

하지만 이 경우 기본적으로 Operations Manager 이벤트 로그에 작성되며, 여기는 특정 이벤트가 로깅되도록 하려는 위치가 아닐 것입니다. 다행히 Microsoft의 수석 필드 엔지니어인 Stefan Stranger가 Windows 이벤트 뷰어에서 이벤트를 만들 수 있는 스크립트를 작성했으며, 이 스크립트는 특정 로그에 작성할 수 있는 더 많은 유연성을 제공합니다. 이 스크립트는 go.microsoft.com/fwlink/?LinkId=120308에서 찾을 수 있습니다. 스크립트는 .cab 파일로 패키지화되어 있습니다. 파일을 다운로드한 다음 마우스 오른쪽 단추를 클릭하여 스크립트를 추출해야 합니다.

Stefan의 스크립트에서 알아 두어야 할 한 가지는 이벤트 소스에 입력된 값에 따라 항목이 작성될 로그가 결정된다는 것입니다. 경고가 올바른 로그에 기록되는지 확인하기 위한 가장 쉬운 방법은 Windows 이벤트 뷰어를 열고 최근 항목의 소스를 찾는 것입니다.

소유자 설정 경고의 소유자를 자동으로 설정하는 것이 유용할 때가 있습니다. 다음은 명령 셸에서 수행할 수 있는 간단한 방법입니다.

 $alert = Get-Alert 
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")

코드의 첫 번째 줄은 특정 경고 개체의 ID를 확인하고 이것을 $alert 변수에 전달합니다. 두 번째 줄에서는 이 변수를 사용하여 소유자를 설정하고, 마지막으로 OpsMgr 데이터베이스에 업데이트가 적용됩니다. 다음 명령으로 경고의 소유자를 확인하면 변경되었음을 알 수 있습니다.

Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner

전체 경고 집합에 대한 소유자를 설정하려면 코드를 다음과 같이 단순화할 수 있습니다.

Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}

모니터링 상태 복원 "모니터링되지 않는" 상태의 에이전트를 발견할 때가 있습니다. 이 경우 모든 에이전트를 전체 모니터링되는 상태로 신속하게 복원한 다음 어떻게 되는지 확인해야 합니다. 명령 셸에서 직접 그림 12의 스크립트를 실행하면 해당하는 모든 에이전트에 전체 모니터링이 복원되어야 합니다.

그림 12 Health Service Store 재설정

 $all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}

그림 12의 코드를 살펴보겠습니다. 변수를 선언한 후 이 RMS에서 모든 에이전트 목록을 확인하고 문제가 있어 보이는 에이전트를 필터링합니다. 그런 다음 필터링된 목록의 모든 에이전트에 대한 Health Service Store를 재설정하는 작업을 비동기로 호출합니다.

관리 팩과 경고 연결 그림 13은 새로운 모든 경고 및 각 경고와 연결된 관리 팩 목록을 확인하는 방법을 보여 줍니다.

모든 관리 팩 이름이 확인되도록 하려면 코드에 몇 가지 트릭이 필요합니다. 사용되는 cmdlet은 경고가 규칙 또는 모니터에서 발생했는지에 따라 달라집니다. 그림 13에서는 Get-Monitor cmdlet에 대해 작은 해결 방법을 구현해야 했습니다. OpsMgr SP1에서는 현재 cmdlet이 새로운 ID 매개 변수를 지원하여 코드가 약간 단순화되었습니다.

그림 13 관리 팩 찾기

Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }  
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}

손쉬운 보고 환경을 업그레이드할 때 설치된 모든 에이전트의 버전을 감사하는 것이 유용할 수 있습니다. 다음과 같이 간단한 스크립트를 사용하여 적합한 보고서를 출력할 수 있습니다.

Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}

그림 14는 스크립트의 출력을 보여 줍니다. 이 스크립트는 systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell에 제공된 예제의 확장 버전입니다.

fig14.gif

그림 14 일부 에이전트의 버전을 보여 주는 출력(크게 보려면 이미지 클릭)

작업 예약 Windows PowerShell 스크립트를 정기적으로 실행하고자 할 수 있습니다. 클라이언트 컴퓨터를 사용하여 OpsMgr 서버에 연결 및 관리하고 OpsMgr 관리 도구를 로컬에 설치했다고 가정해 보겠습니다. 그리고 에이전트 버전 보고서를 매일 실행하고 현재 날짜를 이름으로 사용하는 파일에 출력이 저장되도록 한다고 가정합니다. Windows 기본 제공 작업 스케줄러를 사용하여 로컬 컴퓨터에서 스크립트를 실행할 수 있습니다.

이를 위해서는 powershell.exe(대개 C:\Windows\System32\WindowsPowerShell\v1.0에 있음)로 설정된 프로그램으로 새 작업을 설정합니다. 작업을 만든 후에는 편집하고 명령이 실행되도록 다음과 같이 설정합니다.

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe 
  –Command "& {& 'c:\agent_report2.ps1'}"

그림 15에 표시된 것과 같이 원본 Windows PowerShell 코드에 몇 가지 변경 작업을 수행해야 했습니다. OpsMgr PowerShell 스냅인을 추가하고, OperationsManagerMonitoring 공급자에 매핑된 Monitoring 드라이브를 만들었으며, RMS에 대한 연결을 만들었습니다. 또한 OpsMgr 사용자 지정 Windows PowerShell 스크립트(Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1)를 로드하여 OpsMgr 특정 기능을 로드했습니다.

그림 15 에이전트 버전 일정 예약 스크립트

Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file

그러나 이것이 전부가 아닙니다. 작업이 실행될 때마다 스크립트가 실행되는 시스템에 누군가 로그온할 경우 검은색 콘솔 창이 화면에 나타나는 것을 알 수 있습니다. 이에 대한 간단한 트릭은 Sapien의 Don Jones 및 Jeffery Hicks의 blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell에서 찾을 수 있습니다.

기본적으로 스크립트는 VBScript 내에서 래핑해야 합니다. 이를 위해서는 예약된 작업에서 다음을 호출하는 대신 그림 16과 유사한 코드를 사용해야 합니다.

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"

그림 16 팝업 숨기기

Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths 
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34) 

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0

이제 작업에서는 wscript.exe 프로그램을 사용하고 호출은 다음과 유사합니다.

C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs

마지막으로 자동화된 보고서를 만들고 이 프로세스는 로그온한 사용자에게 보이지 않습니다.

요약

이 문서에서는 OpsMgr 2007에서 사용할 수 있는 새로운 자동화 기능에 대해 대략적으로 살펴보았으며, Windows PowerShell을 사용하여 OpsMgr 관리를 수행할 수 있는 방법에 대해서는 아주 약간만 소개했습니다.

이 문서에서 언급한 모든 분들과 많은 도움을 주신 Pete Zerger, MOM MVP 및 SystemCenterForum.org 설립자께 감사의 말씀을 드립니다.

Marco Shaw는 캐나다 통신 회사의 IT 시스템 분석가입니다. IT 분야에서 10년 이상 일해 왔으며, 최근 Windows PowerShell MVP 상을 수상했습니다. 또한 Marco는 새로운 PowerShell 커뮤니티 웹 사이트 powershellcommunity.org의 커뮤니티 부책임자입니다. Marco의 블로그 주소는 marcoshaw.blogspot.com입니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다.