StoreApp Sample Management Pack
Completed by Brian Wren, Microsoft Consulting Services=
Version 1.0
April 21, 2009
Introduction
This document describes the sample management pack Demo.StoreApp. It provides instructions on setting up the application components monitored by the management pack, a high level discussion of its design strategy, and detail= ed information on its individual contents.
Sample Application
Supporting the management pack is a simulated distribu= ted application serving a number of locations – these could be retail sto= res, restaurants, branch offices, etc. The components of the application are completely simulated to make it easy for = the student to set up in their own environment. It’s not important that the application itself actually work – in fact, it purposely has a rudimentary structure to make it easy to build. What is important is that the read= er understands the components in the environment that the management pack is detecting.
Each location has a dedicated store server and a numbe= r of clients. Employees take order= s on the clients which run a point of sale application. As orders are taken on the client = they are written to the store server which keeps them in a local cache. The store server on a periodic bas= is sends the orders to a central server which uses the file system for a queue= having a folder for each store. The = Store Server writes a file for each order containing the detailed order information. It then stores the file locally in= an archive. A service on the cen= tral server processes each file, stores it in a database, and then deletes the f= ile.
![](3D"StoreAppSampleManagementPack_files/image002.gif")
Figure SEQ Figure \* ARABIC 1 - StoreApp Sample Application
Setting Up the Sample Application
The StoreApp sample application was specifically desig= ned to be easily setup in any environment. The only product required aside from the operating system is SQL Ser= ver, and the server hosting the OperationsManager database could be easily used = for this function. Rather than use custom services, the management pack uses the WMI Performance Adapter (wmiApSrv) to simulate the services on the Central Server and Store Server.= This service is present on all Win= dows servers and only needs to be modified to a startup type of Automatic for the management pack monitors to work properly.=
Central Server
There is expected to be a single central server. This can be any machine running an= y version of either Windows Server 2003 or Windows Server 2008 with the following components.
Registry
Create the following registry keys and values for the = server to be identified as a Store Server.
|
Type |
Name |
Contents |
|
Key |
HKLM\SOFTWARE\Demo\StoreApp |
|
|
Value |
HKLM\SOFTWARE\Demo\StoreApp\DatabaseServer |
FQDN of the Orders database server |
|
Value |
HKLM\SOFTWARE\Demo\StoreApp\DatabaseName |
Name of the Orders database |
|
Value |
HKLM\SOFTWARE\Demo\StoreApp\DatabaseName |
Path to the top level folder for the queues folders |
An example of the Central Server registry is show in <= !--[if supportFields]> REF _Ref228029409 \h Figure 2.
![](3D"StoreAppSampleManagementPack_files/image004.jpg")
Figure 2 - Central Server Sample Registry
Folders
The Central Server has a folder for each store using t= he Store Code used for the folder name. Any number of folders may be created, and the value for Store Code is completely arbitrary. There m= ust be a Store Server for each folder though with a matching Store Code in its registry.
![](3D"StoreAppSampleManagementPack_files/image006.jpg")
Figure SEQ Figure \* ARABIC 3 - Central Server Sample Queue Folders
Store Server
There must be a Store Server for each store, and any n= umber may be included in the test environment.&n= bsp; This can be any machine running any version of either Windows Server 2003 or Windows Server 2008 with the following components.
Registry
Create the following registry keys and values for the = server to be identified as a Store Server.
|
Type |
Name |
Contents |
|
Key |
HKLM\SOFTWARE\Demo\StoreApp |
|
|
Value |
HKLM\SOFTWARE\Demo\StoreApp\StoreCode |
Store Code for the server’s store |
An example of the Store Server registry is show in REF _Ref228029446 \h Figure 4.
![](3D"StoreAppSampleManagementPack_files/image008.jpg")
Figure 4 - Store Server Sample Registry
Store Client
There should be at least one Store Client for each sto= re, and any number may be included in the test environment. This can be any machine running any version of either Windows XP or Windows Vista with the following components= .
Registry
Create the following registry keys and values for the = server to be identified as a Store Client.
|
Type |
Name |
Contents |
|
Key |
HKLM\SOFTWARE\Demo\StoreApp |
|
|
Value |
HKLM\SOFTWARE\Demo\StoreApp\StoreCode |
Store Code for the client’s store |
An example of the Store Server registry is show in REF _Ref228029557 \h Figure 5.
Figure 5 - Store Client Sample Registry
Monitoring Requirements
Following is the logic that the management pack is req= uired to implement. For an actual application, this information would be gathered from the application develo= pers and/or administrators.
Central Server
· Monitor a service called StoreAppProcessing. This serv= ice should be running at all times.
· Track the length of each queue. Collect the number of items in the= queue every 10 minutes. If the numb= er of items exceeds 10, then set the health state to a warning. If it exceeds 20, then set the hea= lth state to an error.
· If the service accesses a file it can’t process, it will generate an error event with a source of StoreApp and an I= D of 101. The StoreCode of the que= ue with the problem file will be in parameter 1 of the event. An operator will need to manually inspect the offending file to determine its problem.
· The state of the orders database should be included in an overall health for the central location.
Store Server
· Monitor a service called ClientReceiver. This service should be running at = all times.
· Collect the memory utilization of the ClientReceiver service.
· If the ClientReceiver service stops, check f= or a dump file at C:\StoreApp\ClientReceiver.dmp. If this file exists, we can assume= that the service crashed from a known problem.&= nbsp; The file can be deleted and the service restarted.
Client
· Monitor a process called StoreAppClient.exe. This exec= utable should be running at all times.
· Monitor for connection to the store server.<= span style=3D'mso-spacerun:yes'> An event will be generated in the Application event log when the application loses the connection to the store server. This will have a sour= ce of StoreAppClient and an ID of 302. A similar event with an ID of 301 will be generated whenever a successful connection is established.
Store
· A state of each store should be available th= at constitutes the health of all application components at the store. Only 80% of clients need to be ava= ilable for the store to show a healthy state.
Application
· A state of the entire application should be available that includes the state of all application components.
Service Model
Figure 6 illustrates the service model for the StoreApp sample application.
![](3D"StoreAppSampleManagementPack_files/image010.gif")
Figure 6 -
StoreApp Service Model
Details on each class are provided in Table 1. Note that each Class Name in this = table is preceded by the common string Demo.StoreApp.
Table 1 - StoreApp Classes
|
Class
Name |
Base
Class |
Description |
|
Application |
System.Service |
Represents the application itself. Provides a health rollup for the entire application. |
|
Central |
System.ApplicationComponent |
Singleton class. Pr= ovides a health rollup for the application components at the central data center. |
|
Stores |
System.ApplicationComponent |
Singleton class. Provides a health rollup for all Stores. |
|
Store |
System.ApplicationComponent |
Separate instance discovered for each store. Provides a health rollup for the application components in each store.&nb= sp; Has the key property StoreCode. |
|
ComputerRole |
Windows.ComputerRole |
Abstract class used as a base for other applicat= ion computer roles. Hosted by W= indows Computer (which is inherited from the base class). Has the StoreCode property inher= ited by the other classes. No key property is required since there will only be a single instance per hosti= ng computer. |
|
ComputerRole.CentralServer |
Demo.StoreApp.ComputerRole |
Represents application on Central Server. Hosted by Windows Computer. Adds a property for QueuePath th= at represents the top level folder for the queue folders. |
|
ComputerRole.StoreServer |
Demo.StoreApp.ComputerRole |
Represents application on Store Server. |
|
ComputerRole.StoreClient |
Demo.StoreApp.ComputerRole |
Represents application on Store Client. |
|
CentralQueue |
Windows.ApplicationComponent |
Represents a folder queue. Hosted by the CentralServer class. Has properties for t= he StoreCode (which is also the name of the folder) and the full path to the folder. |
Discovery
The following table provides the logical method that c=
an be
used to discover each class. =
These
are methods that we have arbitrarily created for our sample application.
Table 2 –Discovery Logic
|
Class |
Method |
Details |
|
ComputerRole.Central |
Registry |
Only discovered on Windows Servers. Existence of registry key at HKLM\SOFTWARE\StoreApp but no value at HKLM\SOFTWARE\StoreApp\StoreCode.<= span style=3D'mso-spacerun:yes'> QueuePath property collected fro= m HKLM\SOFTWARE\StoreApp\QueuePath. DatabaseServer property collecte= d from HKLM\SOFTWARE\StoreApp\DatabaseServer.&n= bsp; DatabaseName property collected from HKLM\SOFTWARE\StoreApp\Databa= seName. |
|
ComputerRole.Store |
Registry |
Only discovered on Windows Servers. Existence of registry key at
HKLM\SOFTWARE\StoreApp and a value at HKLM\SOFTWARE\StoreApp\StoreCode. |
|
ComputerRole.Client |
Registry |
Only discovered on Windows Clients. Existence of registry key at HKLM\SOFTWARE\StoreApp. Sto= reCode property collected from HKLM\SOFTWARE\StoreApp\StoreCode. |
|
Store |
Script |
Instance created for every store server using the collected Store Code. |
|
Central Queue |
Script |
Discovered only on Central Server. One instance created for each fo= lder underneath the QueuePath folder. The StoreCode property is collected from the folder name. The FolderPath property is colle= cted from the full path of the folder. The script itself is heavily commented and should be referenced fo= r details. |
|
Application |
Group Populator |
Singleton class – no discovery required. Group Populator us= ed to create containment relationships. |
|
Stores |
Group Populator |
Singleton class – no discovery required. G= roup Populator used to create containment relationships. |
|
Central |
Group Populator |
Singleton class – no discovery required. Group Populator us= ed to create containment relationships. |
|
Relationship with database |
Registry |
Collect the DatabaseServer and DatabaseName properties from the registry on the Central Server to identify the key properties of the database to build the relationship with. This discovery needs to use a cu= stom workflow since there isn’t a standard workflow to discover a relationship. |
Unit Monitors
Service Monitors
The monitors Demo.StoreApp.Monitor.ClientReceiver and = Demo.StoreApp.Monitor.ProcessingService are standard monitors that track the state of the Windows services on the Central Server and Store Server. These monitors just need to provide the name of the service being monitored.
The management pack specifies the WMI Performance Adap= ter (wmiApSrv) service for both monitors. This is simply for testing to simulate the operation of actual services. This service has a default startup type of Manual. For it to be monitored, the startup type for the service needs to be modified to Automatic.
Performance Monitor
Demo.StoreApp.Monitor.ClientReceiverProcessor monitors= the processor utilization of the Client Receiver service on each Store Server.<= span style=3D'mso-spacerun:yes'> It sets a Warning state if the utilization exceeds 80% for three consecutive samples.
Like the service monitor, the management pack uses the= WMI Performance Adapter (wmiApSrv) to simulate the service.
Process Monitor
Demo.StoreApp.Monitor.ClientApplicationRunning monitor= s for the presence of the client application.&nb= sp; This is simulated in the management pack as Notepad.exe. If at least one instance of this p= rocess is not running, the Store Client is put into an error state.
Event Monitors
Simple Event Monitor
Demo.StoreApp.ConnectionToStoreServer is a simple event reset monitor. If an event wi= th an ID of 302 is received on the client, the monitor will go to an error state. A corresponding 301 ev= ent will reset the monitor to a healthy state.= No additional criteria is required since the monitor targets Store Client where we will only have a single instance for each agent.
Event Monitor with Instance Specific Criteria
Demo.StoreApp.Monitor.BadQueueEntry is intended to det= ect the event on the Central Server generated when the processing service encounters a bad file. This i= s a standard event monitor, but it illustrates the use of the event criteria in relation to the target class. If the rule were targeted at the Central Server class, the criteria could simp= ly include the event source and event ID.&nbs= p; Since there is only a single instance of this class on the agent, th= ere would be only a single copy of the monitor, and this would be sufficient criteria to uniquely identify and set state appropriately. The problem with this strategy is = that the entire Central Server would report an error state when only a single qu= eue was having a problem.
The strategy used in the monitor is to use the Central= Queue class as the target. This cau= ses the state to correctly be associated with the queue as opposed to the server. Since we are expecting multiple instances of the Central Queue class though, simply using the event source and ID would set the state for all queues regardless of which one is having the specific problem – since each instance of the class has its own copy of the monitor. In this case, we need to include criteria to match= the event parameter holding the Store Code with the name of the folder. Each instance still has its own co= py of the monitor, but only the instance with the name matching the particular ev= ent will react to the event.
Script Monitors
Queue Length
The monitor Demo.StoreApp.Monitor.QueueLength is an ex= ample of a monitor that does not support cookdown. This monitor is completely functio= nal but not desirable because of this inefficiency. Each instance of the target Centra= lQueue class will have its own instance of the script. This can be tested by enabling the monitor and noting the number of events indicating the starting of the scri= pt that it generates in the OperationsManager event log. These events will have an ID of 82= 1, and we would expect to get a separate one for each of execution of the script.<= /p>
The other issue with this monitor is that it has the s= cript placed directly in the monitor itself meaning that it can’t be shared with other workflows. In fact= , the rule that collects Queue Length has to have an identical copy of the script. Placing the rule dire= ctly in the monitor also makes presentation of the parameters to be overridden difficult for the end user. <= /p>
Queue Length Cookdown
The monitor Demo.StoreApp.Monitor.QueueLength.Cookdown= uses a custom data source module with a script similar to the previous QueueLeng= th script except that it is written to support cookdown. Instead of gathering information f= or only a single queue, it performs logic similar to the discovery script to enumerate all queues, gathers the information for each, and then returns multiple property bags. The m= onitor is targeted at the Central Queue class and does accept the folder path as a parameter. Within the custom = module though this parameter is used in the Condition Detection to select the individual property bag. Since identical arguments are being passed to the script for all instances of the target class, the agent can cookdown the script into a single instance of cscript.exe for all instances of the target class.
This monitor is also an illustration of the use of a c= ustom monitor type. Since the monit= or is going to use a custom data source, it must use a custom monitor type. The monitor type defines the modul= es and workflow while the monitor provides the values that the logic in the monitor type will use.
Diagnostics and Recoveries
For the Store Server monitor, we have a known condition where the service may crash. = If a particular dump file is present, then we can take that as an indication that the service may be restarted. This is obviously simplistic logic, but it represents a simulation of a real wor= ld scenario where we may be able to programmatically determine if a problem has occurred due to a known condition.
The monitor Demo.StoreApp.Monitor.ClientReceiver has a Diagnostic called Demo.StoreApp.Diagnostic.CheckForDumpFile that runs a scr= ipt checking for the existence of the specified dump file whenever the service = is stopped. It returns a propert= y bag with a simple value of “yes” or “no” indicating whe= ther the file is found.
The Recovery on the monitor is called Demo.StoreApp.Re= covery.ClearDumpFile. This executes a script that clears= the dump file and restarts the service. The recovery is configured to execute after the diagnostic. In addition, it specifies a Condit= ion Detection that checks the property bag output from the diagnostic so that it will only execute if the diagnostic specifies that the dump file was found.=
Rules
Collect Queue Length
The rule Demo.StoreApp.Rule.CollectQueueLength collect= s the number of files in each queue folder using the same script as the monitor Demo.StoreApp.Monitor.QueueLength. This shares the same issues as that monitor – the script does = not support cookdown, and both the monitor and the rule need their own copies of the script. Every time the sc= ript executes, it will create an event in the Operations Manager event log on the Central Server agent with an ID of 821.&nb= sp; This will illustrate the fact that a unique copy of the script is executed for each instance of the Central Queue class.
Collect Queue Length Cookdown
The rule Demo.StoreApp.Rule.CollectQueueLength.Cookdown collects the number of files in each queue folder using the same data source module as the monitor Demo.StoreApp.Monitor.QueueLength.Cookdown. This is more efficient than Demo.S= toreApp.Rule.CollectQueueLength since it supports cookdown and shares a single copy of the script with any other workflow requiring it. = Every time the script executes, it will create an event in the Operations Manager event log on the Central Server agent with an ID of 831. This will illustrate the fact that= only a single copy of the script is executed for all instances of the Central Qu= eue class.