|
Huntland Services Ltd Tel: +44 (0)1392-490518
|
Service
Bounce Asynchronous Script Explained
|
|
|
MOM is supplied with a few scripts to support the BASE Management Packs
installed by default. Most of these scripts are legacy NetIQ ports and
some look as though they were assembled while the building was on fire.
Unfortunately the 'Service Bounce Asynchronous' script is one of
them - although like all the scripts, it does the job it was intended
to do. This script is used as the Response to the following
rules which are all part of the default MOM Management Pack - that is,
the processing rules designed for the management of MOM itself. 1.
Microsoft Operations Manager 2.
Microsoft Operations Manager 3.
Microsoft Operations Manager These three performance threshold rules trap where the Consolidator,
the Agent or the DAS have been leaking memory or handles (same thing really)
and then bounce the OnePoint service. The thresholds they use are
50,000,000 bytes on the Agent, 155,000,000 bytes on the Consolidator and
10,000 handles for the whole OnePoint service. If you look at these rules you will discover that when the script is
launched it is supplied with a parameter called 'ServiceName' (in the
response tab, click the edit button to see what parameters are supplied to a
script) which has been set to 'OnePoint', the MOM service. Armed with
this information you might be forgiven for thinking that you can use this
script to bounce any service just by supplying the name. Unfortunately not. The 'Service Bounce Asynchronous' script contains some hard coded
instructions to kill the OnePoint service regardless of what service name is
passed. If you feed it the name 'Alerter' for example, it stops the
Alerter service and kills the OnePoint service. Even
if this wasn't bad enough, it starts the 'Alerter' service but fails to start
the OnePoint service afterwards as one would expect. There is
another script called 'Service Bounce' supplied with MOM, not
used in any rule by default, which will correctly stop and start any service
when you supply four parameters: 1.
ComputerName 2.
NumAttempts (use 3) 3.
NumSecsBetweenRetries (use 10) 4.
ServiceName The critical instructions are:
What does the script do?
The 'Service Bounce Asynchronous' script should be treated as a
dedicated tool for dealing with the OnePoint service. The
'asynchronous' bit refers to how to get over the delicate problem of killing
the service which is running the script which is trying to kill the
service which is running the script which is trying to kill the
service............... etc. So the script doesn't stop the OnePoint
service directly. Instead it writes the instructions to a file on the
local hard disk called <your Config group
name>_BounceServiceAsync.vbs. The location for this file is in the
profile\Location Settings\Temp folder of the account being used by the
OnePoint service. If, on a managed system, the Agent is running as per
the default using the Local System account the DriveC:\WINNT\Temp folder is
used. The last instructions of the doomed 'Service Bounce Asynchronous'
script are to run the vbs file in a different process : 1.
strCmdLine = "cscript.exe """
& strCmdFile & """ //B" 2.
If Not(oUtil.CreateProcess("", strCmdLine,
False)) Then 'start the script using
cscript.exe The second script then executes these core instructions: 1.
bStopStatus =
oSCM.StopService(strServiceName) 'stop
the service whose name was supplied as a parameter 2.
oUtil.CreateProcess "", "cmd.exe /c
""" & strKillProcPath & """
OnePointService", True 'kill onepoint
(hard coded) 3.
If oSCM.StartService(strServiceName) Then
'start the service whose name was passed as a
parameter 4.
Else 5.
oUtil.CreateProcess "", "cmd.exe /c
del /f /q """ & WScript.ScriptFullName &
"""", False 'delete this
script file The strKillProcPath variable contains the path to Drive:\Program
Files\Microsoft Operations Manager 2000\OnePoint\KillProc.exe which is
shipped with MOM. Notice the last instructions wipes the vbs file
itself. Why it's necessary to stop the service and then attempt to kill
it as well seems a little blood-thirsty. Maybe its just a safety
mechanism in case the OnePoint service is in some unknown or unstable state. Is there any point in fixing this script?
Not really. Only the OnePoint service needs to be
bounced asynchronously, all other services can be dealt with using 'Service
Bounce'. Also the ServiceName parameter passed to the script e.g.
'OnePoint' is not the same parameter used by killproc.exe which takes
the name of the process e.g. 'OnePointService'. The script would
have to be re-written to take two parameters but that would mean modifying
the existing rules. So probably the best solution is simply to
rename the script to stop other MOM administrators from falling into the trap
of using it as a generic service bouncer. Something like 'OnePoint
Service Bounce Asynchronous'. This will not effect the existing rules
as MOM associates scripts with rules by their GUIDs, not their names. |
||