Granular Targeting in Operations Manager (OpsMgr) 2007

아티클
08/24/2016

System Center

Operations Manager 2007에서의 세밀한 대상 지정

Steve Rachui

한 눈에 보기:

기존 대상의 사용
특성 검색의 문제점
제작 콘솔을 사용한 대상 만들기
스크립트 기반의 검색

기존 대상의 사용
제작 콘솔을 사용한 대상 생성
레지스트리 키 사용
레지스트리 값
스크립트를 통한 검색
추가 고려 사항

사용자 지정 모니터링 개체(규칙, 모니터, 그룹 등)를 만드는 작업은 많은 System Center Operations Manager(OpsMgr) 2007 관리자들의 일상적인 업무 중 하나입니다. 그러나 작성하는 모든 개체에 대해 한 가지 공통적으로 떠오르는 질문이 있으니, 바로 어떤 대상을 사용할 것인가 하는 문제입니다.

개체의 올바른 대상을 선택하는 것은 매우 중요하지만, 항상 올바른 접근 방법이 명확한 것은 아닙니다. OpsMgr는 대상 지정을 위한 몇 가지 옵션을 제공하는데, 이 기사에서는 관리자가 각각의 상황에서 적절한 방법을 선택하는 과정에 도움이 될 수 있도록 이 중에서 몇 가지 방법에 대해 알아보겠습니다. 여기서 “클래스”와 “대상”은 같은 의미로 사용될 것입니다.

widget이라는 내부 응용 프로그램을 모니터링해야 한다고 가정해 보겠습니다. 모든 모니터링 규정이 정의되어 있고, widget에 대한 모니터링 개체를 만드는 작업이 시작되었습니다. 그러나 곧 widget에 대한 정확한 대상이 없다는 것을 알게 됩니다. OpsMgr 모범 사례에 따르면 모든 규칙이나 모니터 등은 가능한 구체적인 대상이 지정되어야 원하는 시스템만으로 그 범위를 좁힐 수 있습니다. 이러한 모범 사례에 따르기 위해 OpsMgr가 제공하는 옵션에는 어떤 것이 있을까요?

기존 대상의 사용

기본적으로 OpsMgr에는 방대한 분량의 대상 목록이 있으며 관리 팩을 더 가져올 때마다 이 목록은 늘어납니다. 새 MPO(관리 팩 개체)를 만들고 대상을 결정할 때는 먼저 현재 사용 가능한 항목을 검토하여 기존의 대상을 그대로 사용해도 좋을지 살펴보는 것이 좋습니다. 예를 들어 SMS(System Management Server) 서버 모니터링을 확장하기 위해 MPO를 작성하는 경우, 기본 SMS 서버 관리 팩을 가져오기할 때 함께 추가된 기존 대상을 MPO에 다시 사용할 수 있을 것입니다.

하지만 기존 대상을 그대로 사용하는 것만으로 모든 상황을 해결할 수는 없습니다. 작성하는 MPO에 적당한 기존 대상이 없을 경우 최적화된 대상의 부족 문제를 해결하거나 새 대상을 만들어야 합니다.

몇 가지 단점이 있긴 하지만 일반적으로 사용되는 방법 중 하나는 새 MPO를 필요한 대상을 포함하고 있는 Windows 클라이언트, Windows 서버 또는 다른 적절한 기본 클래스(다시 강조하지만 최대한 구체적이어야 함)로 연결하는 것입니다. 이 방법을 사용할 때는 비활성 상태에서 MPO를 만들어야 함을 주의하십시오. 그런 다음 이 MPO를 실행해야 하는 모든 시스템이 포함된 그룹을 만들고 비활성화된 MPO를 재정의하여 MPO가 그룹 내의 에이전트에 대해서만 활성화되도록 합니다. 이렇게 하면 재정의에 의해 허용된 에이전트에만 MPO가 전달되고 실행되게 됩니다.

이 방법의 단점은 무엇일까요? 일단 이 방법을 사용하면 대상이 더 넓은 클래스(예를 들어 Windows Computer)로 지정됩니다. 따라서 이러한 방법을 사용하여 대상이 지정된, 모니터링되는 모든 MPO는 그림 1과 같이 상태 탐색기에 대상이 지정된 개체로 표시됩니다.

그림 1 재정의에 의해 대상이 지정된 컴퓨터의 상태 탐색기 (더 크게 보려면 이미지를 클릭하십시오.)

이러한 문제는 그저 표면적인 것일 뿐이므로 실제로 크게 문제가 될 부분은 없을지 모르지만, 이러한 방식으로 대상을 지정하면 사용자 지정 모니터링을 실행할 때 Windows Computer와 같은 상위 개체의 상태에도 영향을 주게 됩니다. 따라서 만약 widget 응용 프로그램에 문제가 있다면 대상으로 지정된 전체 개체의 상태에 영향을 주게 됩니다. 모니터링하는 대상이 무엇인지에 따라 이 문제는 별 것 아닐 수도 있지만, 매우 커질 수도 있습니다.

MPO의 대상을 그룹으로 지정하는 것은 일반적으로 OpsMgr의 적절한 방법이 아닙니다. 그렇다면 왜 이 방법을 사용할까요? 예로 든 그룹의 경우 재지정을 위해 사용되었을 뿐, MPO의 실제 대상은 아니기 때문입니다.

다분히 이론적인 얘기로 들리지만 OpsMgr 내의 그룹을 생각해 보십시오. 그룹은 다른 개체와 마찬가지로 엄연한 개체입니다. 개체를 대상으로 지정한다는 것은 이 개체를 소유하고 있는 에이전트에 MPO가 배포된다는 것을 의미합니다.

그룹 개체를 소유하고 있는 에이전트는 무엇일까요? 그렇습니다. 바로 RMS(루트 관리 서버)입니다. 그룹을 대상으로 지정하면 이 그룹을 소유하고 있는 에이전트로 MPO가 전달되므로, MPO가 RMS에만 배포되는 것입니다. MPO의 대상이 적절하게 지정되었다면 MPO에 설정된 단계가 올바른 에이전트로 배포되겠지만 MPO를 비활성화하면 시작하기도 전에 이 절차가 중단되고 말 것입니다.

재정의가 실행되도 기존 대상은 여전히 대상으로 남습니다. 재정의는 비활성화된 상태를 그룹에 속한 일부 에이전트에 대해 활성화할 뿐입니다. 하지만 MPO가 활성화된 대상은 이미 MPO의 원래 대상 중 일부인 것입니다. 이해하기 약간 어려울 것이라 생각합니다.

그렇다면 지금까지 설명한 방법을 사용할 수 없는 상황을 생각해 보겠습니다. 어떤 방법을 사용할 수 있을까요? 남은 방법은 한 가지 뿐입니다. MPO를 위한 새 대상을 만드는 것입니다. 운영 콘솔의 서비스 모니터링 템플릿을 사용해서 만들어도 되고, 제작 콘솔에서 새 대상을 만들어도 됩니다.

하지만 이 방법을 사용하기 전에 특성 검색을 만드는 것은 어떨까요? 간과하기 쉬운, 유용한 옵션이라 생각할 수도 있습니다. 이 방법에 대해 살펴보겠습니다. 레지스트리나 WMI에서 정보를 가져오는 특성 검색을 만들 수 있습니다. 올바르게 작동하려면 특성 검색은 원하는 레지스트리나 WMI를 포함하는 클래스를 대상으로 삼아야 합니다. 일반적으로 이러한 개상은 Windows 클라이언트, Windows Server 클래스, 더 일반적으로는 Windows Computer 클래스가 될 수 있습니다.

특성 검색이라는 단어 자체를 생각해보면, 실제로 어떤 일이 벌어질지 상상할 수 있습니다. 새 특성이 검색되고 기존 클래스를 확장하는 데 사용됩니다. 즉 새 클래스가 결과로서 생성되지만 이는 다른 멤버와 마찬가지로 기존의 클래스일 뿐이고, 단지 새 특성만 보고되었을 뿐입니다. 이를 따져보면 새 특성 검색을 만드는 것이 고유한 대상을 만드는 것과 같은 효과를 내지는 않는다는 것을 알 수 있습니다.

예를 들어 볼까요? widget 제품에 대한 레지스트리 키를 찾기 위해 새 특성 검색을 만들었다고 가정해 보겠습니다. 이 검색은 Windows Computer에 배포되기 위해 대상이 지정되므로 대상은 widget 레지스트리 키를 포함하고 있을만한 모든 에이전트가 될 것입니다.

마법사에서 이렇게 선택하면 Windows Computer 클래스를 확장할 수 없다는 경고가 표시될 것이고(봉인된 관리 팩이 아닌 경우는 경고가 표시되지 않음), 그림 2와 같이 처리를 위해서는 이름이 새로 지정된 대상 클래스를 선택하라는 메시지가 나타납니다. 이는 특성 검색의 목적이 기존 클래스를 확장하는 데 있기 때문에 발생하는 현상입니다.

그림 2 특성 검색은 고유한 클래스를 생성하지 않음 (더 크게 보려면 이미지를 클릭하십시오.)

이제 시스템의 고유한 대상을 만드는 데 사용할 수 있는 서비스 템플릿에 대해 알아보겠습니다. 이는 적절한 서비스가 설치된 경우 사용할 수 있습니다. 서비스 템플릿은 그림 3과 같이 사용이 매우 간편합니다.

그림 3 서비스 템플릿

그러나 한 가지 주의할 점은 템플릿을 사용하면 원하든 원하지 않든 관계없이 추가 MPO가 생성된다는 것입니다. 따라서 서비스 템플릿 사용이 끝나면 추가 개체가 생성되었는지 확인하고 이를 그대로 두어야 할지 결정하는 것이 좋습니다(그림 4 참조).

그림 4 템플릿을 사용하면 개체가 생성됨 (더 크게 보려면 이미지를 클릭하십시오.)

또한 서비스 템플릿은 모든 서비스에 대해 각각의 검색과 새 클래스를 만들게 됩니다. 이는 원하는 결과일 수도 있지만, 너무 세분화될 수도 있습니다. 예를 들어 여러 서비스가 있는 사용자 지정 응용 프로그램의 경우를 생각해 보겠습니다. 이 경우 각 서비스에 대해 새 클래스와 새 서비스 모니터가 생성되게 됩니다. 아마도 이는 원하는 결과가 아닐 것이며, 클래스를 대상으로 하는 각 서비스 모니터에 대해 하나의 클래스만 생성되기를 원할 것입니다.

서비스 템플릿을 사용할 수 없거나 사용하는 것을 원하지 않을 경우, 유일하게 남은 방법은 제작 콘솔을 사용하는 것입니다. 하지만 제작 콘솔 설명서를 보면 알 수 있듯이 이 기능을 올바르게 사용하려면 많은 설명이 필요하며, 이 기사에서 모두 다루기에는 적합하지 않습니다.

따라서 OpsMgr에서 새 대상을 만드는 과정에 대한 간단한 예만 들어 보도록 하겠습니다. 레지스트리 항목을 사용하여 widget 응용 프로그램을 고유하게 식별하는 과정에 대한 두 가지 예를 들고, 스크립트를 사용한 검색의 예를 들어 보겠습니다.

제작 콘솔을 사용한 대상 생성

대부분의 경우, 원하는 대상을 호스팅하는 특정 서버를 고유하게 식별하기 위한 특정한 값이나 키를 레지스트리에서 검색하는 것이 가능합니다. 클래스(대상)를 만들어 widget 레지스트리 키가 있는 시스템을 통해 채울 수 있다면, 이는 고유한 대상을 만드는 가장 쉬운 방법일 것입니다.

첫 번째 예는 단순히 레지스트리 키의 존재 여부를 파악하는 과정을 보여주며, 두 번째 예에서는 레지스트리 키와 연결된 특정한 값을 찾게 됩니다. 전에 언급한대로 레지스트리 특성 검색 규칙을 만들 수도 있고 제작 콘솔에서 검색을 만들 수도 있지만, 다음 예에서 설명하듯이 이 두 가지 방법의 결과는 같지 않습니다. 전자는 기존 클래스를 확장할 뿐이며 후자는 실제로 새 대상을 만들게 됩니다.

레지스트리 키 사용

일단 제작 콘솔을 실행하면 먼저 기존 관리 팩을 로드할지, 새 관리 팩을 만들지 결정해야 합니다. 새 관리 팩을 만들도록 선택하면 그림 5와 같이 마법사가 실행되고, 빈 관리 팩 또는 Windows Application(레지스트리) 관리 팩을 만들 템플릿을 선택하라는 대화 상자가 나타납니다.

그림 5 새 관리 팩을 위한 템플릿 선택 (더 크게 보려면 이미지를 클릭하십시오.)

어떤 것을 선택해도 같은 결과를 얻을 수 있지만, Windows Application(레지스트리) 템플릿을 사용하여 새 관리 팩을 만드는 방법이 더 수월할 것입니다. 단순히 이름을 지정하고 레지스트리 템플릿을 선택하기만 하면 됩니다. 그런 다음 이름 및 설명 화면에서 관리 팩의 이름과 설명을 입력합니다. 여기서 입력한 값은 Operations Manager UI의 관리 팩 노드에 표시됩니다..

다음은 Windows Application 화면에서 응용 프로그램의 설명을 입력합니다. 여기서 입력한 값은 Operations Manager UI의 특성 노드에 표시됩니다. 이제 검색이 얼마나 자주 실행될지 구성해야 합니다. 기본값은 15초로, 너무 자주 실행되므로 성능에 미치는 영향이 클 수 있기 때문에 적당히 조절해야 합니다. 일반적으로 하루에 한 번 이상 검색을 실행하게 되는 경우는 거의 없습니다.

이제 원하는 레지스트리 키/값을 찾는 데 필요한 정보를 입력해야 합니다. 사용 가능한 특성 유형은 여러 가지가 있는데, 여기서는 부울 형식을 사용하여 키의 존재 여부만 확인하면 됩니다.

마지막으로 쿼리 식을 작성합니다. 이미 쿼리 식을 만든 것 같다구요? 그렇지 않습니다. 레지스트리 프로브 구성 창은 검색할 레지스트리 키가 무엇이며 어떻게 검색할지 정의하는 데 사용되며 식 필터 화면은 어떤 값이 예측되는지 정의하는 데 사용됩니다.

자 이제 모든 과정이 끝났습니다. 실제로 만들어진 것은 무엇일까요? 새 클래스를 성공적으로 만든 것일까요? 제작 콘솔에서 서비스 모델 노드를 선택하고 클래스를 클릭해 보면 새 클래스가 만들어진 것을 확인할 수 있습니다. 속성을 확인하여 새 클래스에 대해 더 자세한 정보를 살펴보시기 바랍니다.

검색 정의는 어디에 있을까요? 상태 모델 아래에서 찾을 수 있습니다. 마찬가지로 속성을 확인하여 실제로 어떤 규칙이 만들어졌는지 살펴보십시오.

레지스트리 값

레지스트리 값을 찾는 검색 역시 레지스트리 키를 찾는 검색과 마찬가지로 어렵지 않습니다. 전과 마찬가지로 마법사를 사용하되, 입력할 때 키 대신에 값을 가져오도록 선택하면 됩니다.

초기 템플릿이 완성된 후 마법사를 시작하려면 Health Model(상태 모델) | Discoveries(검색)를 선택합니다. 중간 창에서 마우스 오른쪽 단추를 클릭하고 New(새로 만들기) | Registry (filtered)(레지스트리(필터링됨))를 선택합니다. 항목은 전과 동일하며 이번에는 레지스트리 값을 지정한다는 점만 다릅니다.

너무나 쉽습니다! 새 대상이 생성되면 이제 예는 여기서 끝나지만 관리 팩을 MPO로 채우려면 몇 가지 작업을 더 해야 합니다. MPO는 Operations Manager UI를 통해 만들 수도 있고, 제작 콘솔에서 직접 만들 수도 있습니다. 양쪽 다 좋은 방법입니다.

그러나 한 가지 기억해야 할 점은, 운영 콘솔에서 만든 MPO를 제작 콘솔에서 열면 원래 지정한 이름이 아니라 UIGenerated라는 이름으로 시작하는 새 이름으로 대체된다는 것입니다. 이 때문에 MPO의 기능이 달라지는 것은 아니지만 제작 콘솔에서 특정한 MPO를 찾으려고 할 때 혼란의 여지가 있으므로 기억해 두십시오.

어떤 방법을 선택하든, 이제 규칙을 전달하는 데 사용할 새 클래스가 만들어질 것입니다. 이 새 클래스와 검색이 어떻게 작동할지 어떻게 알 수 있을까요? 새 클래스의 인벤토리 검색 정보를 보면 됩니다. 그림 6과 같이 새 모니터에 대한 올바른 대상임이 표시될 것입니다.

그림 6 새 클래스가 모니터에 대한 올바른 대상임을 확인 (더 크게 보려면 이미지를 클릭하십시오.)

스크립트를 통한 검색

기존 관리 팩에서 스크립트 기반의 검색을 만들려면 관리 팩을 제작 콘솔로 로드합니다. 처음부터 새로 만드는 경우는 제작 콘솔을 열고 새 관리 팩을 만들도록 선택하면 됩니다.

이 방법은 스크립트 기반의 검색이기 때문에, 선택 가능한 옵션은 빈 관리 팩을 만드는 것 뿐입니다. 첫 번째 단계는 스크립트로 채워질 클래스를 정의하고 원하는 클래스 속성(특성)을 지정하는 것입니다. 스크립트에서 제어되는 이 클래스에서 정의할 수 있는 속성은 FileName, FileDirectory 및 FileDescription이며 그 방법은 곧 설명하겠습니다.

또한 DisplayName 속성 역시 System.Entity 클래스에서 상속되며 스크립트로 제어할 수 있습니다. 이 목록에 표시되는 특성만 검색 스크립트에서 제어할 수 있으므로, 원하는 모든 항목이 표시되었는지 확인하시기 바랍니다. 또한 각 속성(특성)을 선택하면 속성에 대한 정보가 오른쪽에 표시되므로 검토해 보시기 바랍니다. 각 속성(특성)에 대한 표시 이름 항목은 반드시 입력해야 합니다. 이 부분을 입력하지 않으면 검색 정보가 반환될 때 검색된 인벤토리와 같은 OpsMgr 환경의 열 머리글이 비어 있게 되므로 좋지 않습니다.

클래스가 정의되었으므로 이제 스크립트 기반의 검색을 만들 차례입니다. Health Model(상태 모델) | Discoveries(검색)로 이동하십시오. 마우스 오른쪽 단추를 누르고 New(새로 만들기) | Script(스크립트)를 선택하여 검색을 만듭니다. 여기서 많은 정보를 선택할 수 있습니다. 먼저 General(일반) 탭을 보면 검색의 이름을 지정하고 검색이 실행될 대상을 지정할 수 있습니다. 다시 한번 강조하지만 대상을 지정할 때는 구체적으로 지정하십시오.

이 기사의 목적상 여기서는 Windows Computer를 선택하는 것이 맞겠습니다. Discovered Types(검색할 유형) 탭에서는 어떤 유형의 개체를 검색할 것인지 구성할 수 있습니다. 여기 표시되는 검색할 유형의 이름은 전에 정의한 클래스 이름에 해당합니다.

다음은 Configuration(구성) 탭으로 이동하여 스크립트가 생성될 때 자동으로 만들어진 정보를 확인합니다. (스크립트를 보고 실행 일정을 확인하려면 Configure(구성)를 선택하십시오.) Configure(구성) | Script(스크립트) | Parameters(매개 변수)를 선택하면 Parameters(매개 변수) 상자가 나타나므로 이 또한 살펴보시기 바랍니다. 나열된 매개 변수를 기억해 두십시오. 이 기사의 뒷부분에서 이에 대해 설명할 것입니다.

스크립크가 실행되면 검색이 진행되고 그 결과는 그림 7과 같이 OpsMgr로 전송됩니다. 간단한 스크립트이지만 스크립트 기반의 검색에 필요한 핵심 요소는 모두 파악할 수 있을 것입니다.

그림 7 검색 스크립트

Option Explicit
Dim oArgs
Set oArgs = WScript.Arguments

Dim oAPI

  'All of the work to submit discovery data is done in the context of
  'API's defined in the OpsMgr 2007 SDK.  Creating the oAPI object allows
  'access to the OpsMgr 2007 scripting environment
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim SourceId, ManagedEntityId, targetComputer

  ' SourceId is the GUID of the discovery object that runs the script.
SourceId = oArgs(0)

  ' ManagedEntityId is the GUID of the computer class that is targeted by the script.
ManagedEntityId = oArgs(1)

  ' targetComputer is the Fully Qualified Domain Name
  ' of the computer targeted by the script. The FQDN
  ' is in Arg(2) of the command prompt.
targetComputer = oArgs(2)

Dim oFSO, oDiscoveryData, oInst

  'This operation sets the stage for creating new discovery data.  Note that the
  'values passed to the CreateDiscoveryData function are variables that are defined
  'by the command line when executed.  The parameters box was displayed earler.  This
  'is where the command-line parameters required by the CreateDiscoveryData object are 
  'defined and passed to the script.
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

  'This section defines objects needed to access the file system environment
Set oFSO = CreateObject("Scripting.FileSystemObject") 
If (oFSO.FolderExists("C:\WServer")) Then 

    'Assuming a folder called WServer was found on the root of the C drive, the script proceeds to create a new
    'class instance.  Once it's created, a number of property (attribute) values are filled in; note that all 
    'three of the properties (attributes) defined on the class are used in the script along with one property
    '(attribute) from the windows computer class.  Note the difference in how the script refers to properties 
    '(attributes) defined in the local class vs. a class that is accessed by reference.  Also note the Name field
    'as defined in the script.  Here the name is a friendly name that easily maps back to a known class name.  
    ' When the management pack is saved and imported into the Operations Console and the script delivered to the
    ' agents, these name values will no longer be friendly, they will be converted to the appropriate class GUID.  
    'Normally these converted values wouldn't be seen, but if the script directly on the agent is examined, 
    'the difference will be seen. Note that if the script attempts to define/use a property (attribute) 
    'that has not been defined in the referenced class, validation errors will be displayed.
  Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']$")
  Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", targetComputer)
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileName$", "TestFileName.exe")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDirectory$", "TestFileDirectory")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDescription$", "TestFileDescription.exe")

    'Class Instance has now been created so the AddInstance method of the CreateDiscoveryData class is used to add
    'the completed instance.  From there the script returns the discovery data to OpsMgr for further processing.
  Call oDiscoveryData.AddInstance(oInst)
  Call oAPI.Return(oDiscoveryData)
End If

이 관리 팩을 OpsMgr로 가져오기하면 그림 8과 같이 올바른 시스템이 검색됩니다. 스크립트 내에 정의된 각 속성(특성)이 연결된 값과 함께 UI에 표시됨을 알 수 있습니다.

그림 8 스크립트를 통한 검색 (더 크게 보려면 이미지를 클릭하십시오.)

스크립트를 보면 검색된 항목에 대한 값이 직접적으로 전달되거나 값을 통해 전달됨을 알 수 있습니다. 또한 앞서 설명했듯이 특정 속성(특성)의 표시 이름 필드를 비워두면 그림 8과 같이 FileName, FileDirectory 및 FileDescription의 열 머리글도 비어 있게 됩니다.

추가 고려 사항

버전 정보의 유지 제작 콘솔을 사용하다 보면, 완성하기 전에 몇 번의 수정을 거치는 것이 일반적입니다. OpsMgr에서 이러한 수정 작업을 할 때마다 버전 번호가 증가하도록 하십시오.

버전 번호는 제작 콘솔에서 File(파일) | Management Pack Properties(관리 팩 속성)를 선택하면 볼 수 있습니다. 버전 번호를 증가시키지 않으면 새 관리 팩을 기존 버전의 관리 팩으로 가져올 때 버전 번호가 그대로 유지되므로 혼동될 수 있습니다.

봉인 또는 미봉인 관리 팩을 완성하면 프로덕션 환경을 위해 봉인해야 할지, 아니면 봉인되지 않은 채로 유지해야 할지 선택해야 합니다. 관리 팩을 봉인되지 않은 상태로 유지하면 재정의된 내용을 관리 팩에 직접 저장할 수 있다는 등 몇 가지 장점이 있습니다. 그러나 프로덕션 환경으로 가져갈 때 사용자 정의 관리 팩을 봉인해야 하는 몇 가지 분명한 이유도 있습니다.

사용자 정의 관리 팩을 프로덕션 환경에서 사용하기 위해 봉인하는 것은 권장되는 모범 사례입니다.
관리 팩을 봉인하면 더 확실한 버전 제어와 변경 내용 제어가 가능합니다.
관리 팩을 봉인하면 동일한 운영 절차를 사용자 정의 및 상업용 관리 팩에도 사용할 수 있습니다. 사용자 정의 관리 팩과 상업용 관리 팩에 대해 재조정 내용의 저장 위치 등과 같은 절차상 차이가 있게 되면 여러모로 혼란의 소지가 많습니다.
봉인되지 않은 관리 팩에서 만들어진 클래스는 같은 관리 팩에 저장된 다른 MPO에서만 보고 사용할 수 있습니다. 그러나 봉인하면 MPO의 저장 위치에 관계없이 개체를 사용할 수 있습니다.
봉인되지 않은 "원본" 관리 팩의 라이브러리를 실수로 변경하지 않도록 방지하려면 OpsMgr 관리자가 이를 유지 관리해야 합니다.

대상에 대해 완벽히 이해하는 것은 OpsMgr를 성공적으로 사용하기 위해 반드시 필요한 과정입니다. Rule and Monitor Targeting Best Practices(규칙 및 모니터 대상 지정의 모범 사례)라는 문서를 .pdf 형식으로 go.microsoft.com/fwlink/?LinkId=125048에서 다운로드할 수 있으므로 읽어 보시기 바랍니다. 서로 다른 대상과 각각 어떤 경우에 사용하기 적당한지에 대한 매우 유용한 참조 자료를 얻을 수 있을 것입니다.

Steve Rachui는 Microsoft Premier Field Engineering 그룹의 지원 전담 엔지니어입니다. Steve는 SMS를 버전 1.2에서부터, MOM을 버전 2000에서부터 지원해 왔습니다. 문의 사항이 있으면 steverac@microsoft.com으로 연락하시기 바랍니다.

추가 리소스