System Center
Operations Manager 2007 中的細微鎖定目標
Steve Rachui
綜覽：
- 使用現有的目標
- 屬性探索的問題
- 透過製作主控台建立目標
- 指令碼式探索
目錄
使用現有的目標
透過製作主控台建立目標
使用登錄機碼
登錄值
經由指令碼探索
其他考量事項
建立自訂監視物件 (規則、監視器、群組等) 是許多 System Center Operations Manager (OpsMgr) 2007 系統管理員的例行工作。每個所要製作的物件，都必須回答一個共同問題 — 要使用什麼目標？
為物件選擇正確的目標至關重要，但是恰當的方法不一定都很顯而易見。OpsMgr 提供許多用於鎖定目標的選項。本文將探討當中的幾個選項，目標是要幫助系統管理員針對每個案例選擇適當的方法，文中會交替使用「類別」和「目標」等詞。
假設您有一個稱為 Widget 的內部應用程式需要監視。所有監視規格都已定案，而為 Widget 建置監視物件的工作也已展開。然而，您很快就發現到 Widget 並沒有明確的目標！根據 OpsMgr 最佳作法，所有規則、監視器等都應該盡可能鎖定目標為特定的物件，以便將散發的範圍限制為感興趣的系統。OpsMgr 中有哪些選項可以幫助您達到此最佳作法呢？
使用現有的目標
OpsMgr 預設包含了一長串的目標清單，隨著匯入越來越多管理組件，這份清單也會越來越長。當您建立新管理組件物件 (MPO) 並考慮目標時，先檢閱一下可用的項目，看看其中有沒有適用的預先存在目標。比方說，若您建置 MPO 是為了擴充 System Management Server (SMS) 伺服器監視，隨預設 SMS 伺服器管理組件一同匯入的現有目標很可能可以重複用於您的 MPO。
然而，使用預設目標不一定永遠行得通。如果可用的目標對於建立的 MPO 不夠明確，您可以下點功夫打造最佳目標，或是乾脆新建一個目標。
一個常見的方法 (不過有些缺點) 是將新的 MPO 與 Windows 用戶端或 Windows 伺服器類別，或與任何其他包含必要目標的適當基底類別 (再次強調，盡可能明確) 建立關聯。這麼做的時候，務必在停用狀態下建立 MPO。接下來您可以建置一個群組來包含這些 MPO 必須執行的所有系統，然後覆寫停用的 MPO，只針對群組中的代理程式啟用 MPO。這可讓 MPO 只在覆寫所允許的代理程式上傳送和執行。
那麼這個方法有什麼缺點呢？首先，使用這種方法會鎖定較廣泛的物件類別 (比方說，Windows 電腦)，所以透過這種方式鎖定的所有受監視 MPO 都會顯示在健全狀況總管中的目標物件下 (見 [圖 1])。
[圖 1] 顯示覆寫鎖定之電腦目標的健全狀況總管 (按一下以放大影像)
這其實只是表面的，因此在特定環境內可能不構成問題。但是以這種方式鎖定目標會使父物件 (例如 Windows 電腦) 的健全狀況狀態在自訂監視器受到影響時產生變化。因此，若是 Widget 應用程式有問題，整個目標物件的健全狀況也可能受到波及。視監視的項目而定，這可能不是那麼明顯。
鎖定 MPO 目標到群組這種方法在 OpsMgr 中通常不太恰當 — 那這為什麼可行？記住，這些範例中的群組是當作覆寫，並不是 MPO 實際的目標。
這看起來似乎是賣弄文字，但想想看 OpsMgr 中的群組。群組是物件，跟任何其他物件沒什麼兩樣。當物件被選作為目標時，就表示提到的 MPO 會被部署到擁有目標物件的代理程式。
那麼，擁有群組物件的是哪個代理程式呢？沒錯，正是 Root Management Server (RMS)。鎖定目標到群組將傳遞 MPO 到擁有該群組的代理程式，也就是說 MPO 只會部署到 RMS！假如 MPO 適當鎖定目標，等於是舖好了將 MPO 部署到正確代理程式的路，但是停用 MPO，您等於是在該程序沒開始前就把它停止了。
在覆寫沒出現前，現有的目標仍舊是目標 — 覆寫只是根據群組成員資格將幾個代理程式的停用狀態變更成啟用。但是啟用 MPO 的代理程式早已是 MPO 原始目標的一部分。我知道剛開始有點複雜。
現在考慮一下要是先前討論的辦法沒有一樣可行，您要怎麼辦呢？只剩一個選項：專門為 MPO 建立一個新目標，您可以使用操作主控台中的服務監視範本，或是在製作主控台中建立新目標來進行這個動作。
然而，在考慮進行這些動作之前，何不建立一個屬性探索？您可能認為我們忽略了這個可行選項，我們就來討論一下吧。您可以建置屬性探索從登錄或 WMI 取得資訊。但要執行這個工作，屬性探索必須鎖定目標到內含相關登錄或 WMI 項目的類別。常見的目標有 Windows 用戶端或 Windows Server 類別，甚至是更普遍的 Windows 電腦類別。
請注意，屬性探索一詞本身暗示著實際發生的情況：探索到新屬性，並將它用來擴充現有類別。沒錯，結果是建立了新類別，但它其實是含有所有相同成員的舊類別，只是報告了新屬性罷了。有鑑於此，您可以看出建置新屬性探索跟建立真正唯一的目標並不一樣。
舉個例子來看看，假設為了尋找 Widget 產品的登錄機碼而建立了新屬性探索。這個探索已鎖定目標要部署到 Windows 電腦，因此它會包含可能具有 Widget 登錄機碼的所有代理程式。
在精靈中做出這個選擇之後，出現一個警告，指出 Windows 電腦類別無法擴充 (畢竟它是在密封的管理組件中，若非密封的管理組件，就不會有這類警告)，並且顯示重新命名過的目標類別，讓您使用這個選項繼續進行 (見 [圖 2])。會發生這種情況是因為屬性探索的目標是要擴充現有的類別。
[圖 2] 屬性探索並不會建立唯一類別 (按一下以放大影像)
現在讓我們討論一下服務範本，在根據安裝的服務找到的系統上，可用它來建立唯一目標。服務範本使用起來非常簡單，[圖 3] 顯示一個範例。
[圖 3] 服務範本
不過要注意的是，使用範本可能會建立超出您預期的額外 MPO。所以在使用服務範本之後，最好檢查看看建立了什麼額外的物件，並決定是否應該保留這些物件 (見 [圖 4])。
[圖 4] 使用範本時建立的物件 (按一下以放大影像)
另外，服務範本也會為每一個服務建立探索和新類別。這可能正巧是您想要的，也可能過於細微。舉例來說，假設您的自訂應用程式有多項服務。那麼在這種情況下，每項服務都會建立一個新類別和新服務監視器！比較理想的監視方法可能是，擁有單一類別，並且讓每個服務監視器只鎖定目標到該類別。
假如您不能或不想使用服務範本，就只剩下使用製作主控台一途。只消看一眼製作主控台說明文件，就會發現若要正確使用此功能，必須深入討論一番 — 這已經大幅超出本文的討論範圍。
儘管如此，舉幾個使用製作主控台在 OpsMgr 中建立和填入目標的範例，當然是沒什麼問題。我將舉兩個例子再次介紹使用登錄項目唯一識別 Widget 應用程式的作法，舉第三個範例來示範利用指令碼進行探索。
使用製作主控台建立目標
在許多情況下，您可以掃描目錄以尋找特定的值或機碼，以便唯一識別感興趣的伺服器 (主控所需目標)。如果 Widget 登錄機碼所在的系統上可建置和填入類別 (目標)，那麼要建立唯一目標就很簡單。
我的第一個範例會直接尋找登錄機碼是否存在，來逐步完成這個動作。第二個範例則是尋找與該登錄機碼相關的特定值。請注意，雖然您可以在製作主控台內建立登錄屬性探索規則 (如前文所述) 和探索，但如下一個範例中示範的，這兩者並不會達到相同的結果 — 前者只會擴充現有的類別，而後者實際上會建立新目標。
使用登錄機碼
當製作主控台第一次啟動時，您必須選擇是要載入現有的管理組件，還是新建管理組件。當您選擇建立新管理組件時，會出現一個精靈，並讓您為空白的管理組件或是 Windows Application (Registry) 管理組件選擇一個範本 (見 [圖 5])。
[圖 5] 為新管理組件選擇範本 (按一下以放大影像)
使用任一者都能達成相同的效果，但使用 Windows Application (Registry) 範本來建立新類別很容易。您必須直接提供名稱，然後選擇登錄範本。接下來，您必須在 [名稱及描述] 畫面上，提供管理組件的名稱和描述。此處要輸入的值是顯示在 Operations Manager UI 的管理組件節點下的值。
接下來在 [Windows 應用程式] 畫面提供應用程式的描述。此處輸入的值將是顯示在 Operations Manager UI 的 [屬性] 節點下的值。然後是設定探索應該多久執行一次。此處的預設值是每 15 秒一次，這可能過於頻繁。權衡快速探索的需要與探索過於頻繁所產生的效能衝擊。一般來說，並沒有什麼理由非得每天執行一次以上的探索。
現在填寫尋找您感興趣的登錄機碼/值所需的詳細資料。可用的屬性類型有好幾個，如果您只是想要檢查機碼是否存在，請使用布林值類型。
最後是建置查詢運算式。這看起來像是重複的工作 — 您不是才剛剛建置查詢運算式嗎？實際上並不是，[登錄探查設定] 畫面是用來定義要尋找的登錄機碼，以及尋找的方法。而 [運算式篩選器] 畫面則是用來定義預期的值。
那麼所有這些動作都完成後，您實際上建立了什麼？您達到建置新類別的目標了嗎？在製作主控台中，選取服務模型節點，並且在類別上按一下。注意一下新類別已經建立，查看屬性以進一步了解這個新類別。
那麼探索定義呢？查看健全狀況模型，留意探索規則 — 同時也檢閱一下此處的屬性來看看規則實際上是怎麼建置而成的。
登錄值
建置探索來尋找登錄值，而不是登錄機碼，也一樣簡單。再次使用精靈，不過這次請修改輸入來提取登錄值，而不是機碼。
若要在初始範本完成後起始精靈，請巡覽至 [健全狀況模型] | [探索]。在中間窗格內，按一下右鍵並選取 [新增] | [登錄 (已篩選) (Registry (filtered))]。輸入的內容跟之前的一樣，只是這次要指定登錄值。
就是這麼簡單！新目標既已建成，範例也在此告一段落。但請注意，為了使用 MPO 填入管理組件，另外還需要進行一些動作。MPO 可以透過 Operations Manager UI 或直接在製作主控台中建立 — 兩種方法都可行。
不過，您必須謹記，假如您從操作主控台中建立的製作主控台裡面開啟 MPO，它並不會使用您原本的命名，而是會以 UIGenerated 為開頭的字串來取代您取的名稱。雖然這完全不會影響 MPO 的功能，但是若要在製作主控台中尋找特定 MPO，這可能會令您飽受挫折感。
無論您選擇哪種方法，都會建立一個可用來傳遞規則的新類別。但您要怎麼確定這個新類別和探索有用呢？您可以查看一下新類別的已探索清查資訊，另外新類別還會顯示成新監視器的有效目標 (如 [圖 6] 所示)。
[圖 6] 新類別是監視器的有效目標 (按一下以放大影像)
經由指令碼探索
若要在現有的管理組件內建立指令碼式探索，請將管理組件載入製作主控台中。如果您是從頭開始，請開啟 [製作主控台]，並選擇建立新管理組件。
因為這是指令碼式探索，所以唯一適用的選項是建立空白管理組件。這個程序的第一個步驟是定義要填入指令碼的類別，以及感興趣的類別屬性。FileName、FileDirectory 和 FileDescription 都是此類別可定義的可用屬性 (可在指令碼中操控)，我待會兒會示範給您看。
此外，DisplayName 屬性是繼承自 System.Entity 類別，而且也可以由指令碼操控。請注意，只有出現在此清單內的屬性可以透過探索指令碼加以操控，因此請確定您感興趣的項目顯示在此。另外也要注意，當選取各個屬性時，右方會出現與該屬性相關的詳細資料。別忘了填寫每個屬性的 [顯示名稱] 項目。如果留白未填，會傳回探索資訊，但 OpsMgr 環境 (例如在 [已探索的清查] 檢視中) 內的欄標題會是空白的。
定義了類別，您就可以建立指令碼式探索了。巡覽至 [健全狀況模型] | [探索]。按一下右鍵並選取 [新增] | [指令碼]，然後建立探索。這裡有一籮筐的資訊。首先，一般索引標籤可讓您為探索命名，並提供應該執行探索的目標。請記住，定義目標時盡可能具體。
基於本文的目的，適合使用 [Windows 電腦]。在 [找到的類型] 索引標籤上，設定要探索的物件類型。請注意此處找到的類型名稱與稍早定義的類別名稱相符。
接下來是 [設定] 索引標籤，當中會顯示在定義指令碼後自動產生的資訊 (選取 [設定] 來查看指令碼和排定執行指令碼的時間)。另外也請注意 [參數] 方塊 (可透過選取 [設定] | [指令碼] | [參數] 來存取)。看一下列出的參數 — 我會在本文稍後參考到。
[圖 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] 經由指令碼探索 (按一下以放大影像)
分析一下指令碼，不難發現已探索項目的值可以明確的方式或透過變數來傳遞。另外還要記住前文提到的，假如把類別當中特定屬性的 [顯示名稱] 欄位留白的話，欄標題 FileName、FileDirectory 和 FileDescription (見 [圖 8]) 也會空白。
其他考量事項
追蹤版本 使用製作主控台時，完成之前產生多次修訂版本是很正常的。您必須確定用於 OpsMgr 的每個修訂版本都以累加的版本號碼儲存。
版本號碼是在製作主控台中透過選取 [檔案] | [管理組件內容] 來存取。若未遞增版本號碼，可能會導致新管理組件以相同的版本號碼匯入到現有的管理組件上，因而在匯入期間產生混淆。
密封或不密封？當管理組件完成時，您必須決定是否應該將它密封用於生產用途，還是保持不密封。不密封管理組件有些優點，像是能夠直接在管理組件儲存覆寫等。但是在將自訂管理組件放入生產環境之前將它密封起來的理由更充分：
- 密封自訂管理組件以用於生產是最佳作法。
- 密封可達成更嚴謹的版本控制和變更控制。
- 密封容許自訂和商用管理組件使用相同的作業程序。要求不同的程序，例如要把自訂管理組件和商用管理組件的覆寫放在哪哩，會產生許多混淆。
- 在未密封管理組件內建立的類別，只有存放在相同管理組件中的其他 MPO 看得見和使用得到。密封讓物件可重複使用，無論 MPO 存放在哪裡都一樣。
- 未密封的「來源」管理組件程式庫可在 OpsMgr 系統管理員的控制下進行維護，以防止意外或未預期的變更。
充分了解目標是成功使用 OpsMgr 的利器。go.microsoft.com/fwlink/?LinkId=125048 上有提供標題為「掌握和監視鎖定目標的最佳作法」的海報 (.pdf 格式)。您會發現這是了解不同目標及適用時機的一項非常實用的參考資料。
Steve Rachui 在 Microsoft 的專業領域工程 (Premier Field Engineering) 小組擔任專屬支援工程師。他從 SMS 1.2 版就開始支援 SMS，從 MOM 2000 版以來便一直支援 MOM。您可以透過電子郵件與 Steve 聯絡：steverac@microsoft.com。