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.

Unsealed MP Backup with Retention Period

A small expansion of Pete's MP Export for Disaster Recovery. Here is an Management Pack that exports all the unsealed MP's once a day to a folder. The folder name is the date of the backup. Backups older than 7 days will be deleted.

Download the Management Pack

---Update---

Link to the MP has been fixed

Clustering

I believe that this sketch by our intern clearly indicates his feelings on clustering in Ops Mgr. Not sure how much I disagree with his opinion.

Event description in Monitor or Rule

When creating an alert based on the Event description, this property is missing from both the Authoring console and the Ops console.

To be able to use the Event description you must add this property.



This example will capture Event with ID zero and the description containing the substring "Error 11" or "Error 17"

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

Data Warehouse Query

If you have multiple management groups rolling up to a single data warehouse here is a query that will allow you to return a computer name and its associated management group. Not great or anything but the first attempt at digging in to the db.

SELECT ManagedEntity.DisplayName, ManagementGroup.ManagementGroupDefaultName
from OperationsManagerDW.dbo.ManagedEntity
INNER JOIN OperationsManagerDW.dbo.ManagementGroup ON
ManagedEntity.ManagementGroupRowId
= ManagementGroup.ManagementGroupRowId
WHERE fullname like 'Microsoft.Windows.Computer:%'

XPath statements to display event data in monitors and rule-generated alerts.

http://goteamshake.com/?p=31

Here are the XPath statements to display event data in monitors and rule-generated alerts.

Monitors

$Data/Context/EventDescription$

Rule-Generated Alerts

$Data/EventDescription$