Initiate Maintenance Mode from an Agent (no extras installed)

---Update---

Updated version of this MP at http://derekhar.blogspot.com/2009/11/new-agent-maintenance-mode.html

---------

This post will detail a method to initiate Maintenance Mode from an agent managed computer using a vbscript. This method is useful in the case where the people doing patching are not the same people who use the Operations Console and when you cannot dictate what is to be installed in the server. Clive Eastwood's AgentMM for example, if run remotely requires .NET 3.0, Operations Manager specific dll's, Admin permissions on OpsMgr and the ability to connect to the SDK service on the RMS.

Using this method, the person running the command needs to have absolutely no permissions on Ops Manager. All of the components required to have this function are part of a standard OS with and agent installed. It works through Gateways so can be used in firewalled or untrusted environments if you have a gateway in place.

There are 3 parts to this solution:

1) A VBScript on each managed computer that writes an event to the local event log.

2) A Management pack containing an rule that detects this event and runs a response on the RMS.

3) The response executes a Powershell script on the RMS that puts the server in to Maintenance Mode. I have borrowed pieces of the powershell script from Boris.

VBScript

Powershell Script

Management Pack

The vbscript is pretty simple and just writes an event to the event log that indicates the length of time Maintenance Mode should remain on. This time is passed as a parameter to the script.

Usage: MaintModeOn 4

- This command turns on Maintenance Mode for 4 hours

The single rule in the management pack picks up the event from the Application Log with event ID of 0, with a source of WSH and where the description contains the words "Maintenance Mode". In response, the rule runs the Powershell script MaintModeON.ps1 and passes to it two parameters -the name of the computer where the script was run and the event description.

The Powershell script puts all three pieces of an agent in the Maintenance Mode. This Powershell script should be copied to the System Center Operations Manager 2007 program folder on the root management server. If you have clustered the RMS it should be in the folder on both nodes.

---Update---

I have updated the links since google appears to have taken down the site hosting the files.

Embed a Powershell Script in a Management Pack

- Updated -

OpsMgr R2 allows you to embed powershell scripts in a MP - See this MP for an example - http://derekhar.blogspot.com/2009/11/new-agent-maintenance-mode.html

----------

If you want to run powershell, perl or any other scripts not run by cscript.exe from a management pack then you invariably had to create the script and distribute it across all the servers where it needed to run. This could easily become quite complex maintaining all these scripts in multiple different locations. If you are in a situation where you have multiple management groups and none of them are quite the same then you could have multiple different versions of the script and the rule that would call the script.

To avoid this problem it is now possible to embed other scripts in a management pack, not just vbscript and jscript.

To explain how this is done we need to break in to the XML. Open the image below to view the full command. This would be executed using on a recurring basis using a System.Scheduler datasource.


The Write Action aboves enables proxying for all management servers. This check is quite easy to do using the command shell alias.

<ApplicationName>%systemroot%\System32\windowspowershell\v1.0\powershell.exe</ApplicationName>

This line launches the Powershell exe. Remember that Powershell must be installed on any server you are targeting the rule at. The same goes for any other script language that you wish to use.


<WorkingDirectory>%MOMROOT%</WorkingDirectory>

The %MOMROOT% variable point to the Installation path of OpsMgr. This is useful when targeting Powershell scripts at the RMS or Management servers as it allows you to easily load the Command Shell Snap-in. This then gives access to all the Command Shell aliases.


<CommandLine>-Command "&amp; '$File/EnableProxy.ps1$'"</CommandLine>

The arguments being passed specifies to run the script $File/EnableProxy.ps1$. After this the file must be entered.


<Files>
<File>
<Name>EnableProxy.ps1</Name>
<Contents>

The name of the script must match the command line name. While I have not tested this there appears to be the ability to embed multiple files here.

Now we drop into the script itself. This rule is targeted to run only on the RMS so $rootMS is set as localhost. The next 3 lines load the Command Shell snapin, and opens the connection to the local management group.

$rootMS="localhost"
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
set-location "OperationsManagerMonitoring::";
new-managementGroupConnection -ConnectionString:$rootMS;


Here is an example Management Pack

Property bags and Variant Types

When using script based monitors the name value pairs get returned in what is called a propert bag. A property bag is simply a blob of XML that looks like this:


<DataItem type="System.PropertyBagData" time="2007-07-16T23:10:53.1294962+01:00" sourceHealthServiceId="8FD1B472-1464-691B-9BF7-E3AC669C2310">
<Property Name="scan.dat" VariantType="3">19</Property>
<Property Name="names.dat" VariantType="3">19</Property>
<Property Name="clean.dat" VariantType="3">19</Property>
</DataItem>

The XML describes that this is a property bag, that date/time that it was submitted to the management server and the properties contained in the property bag.

The VariantType describes the type of the value that is returned. The variant types are:

Empty = 0
Null = 1
Short = 2
Integer = 3
Single = 4
Double = 5
Currency = 6
Date = 7
String = 8
Object = 9
Error = 10
Boolean = 11
Variant = 12
DataObject = 13
Decimal = 14
Byte = 15
Char = 16
Long = 17