Derek Ops Manager

Moving On

2010-02-12T13:22:00.003Z

I am moving on to a new role in my current job. I will no longer be working on OpsMgr related topics. I will leave this blog and its content available but I currently have no plans for any more posts.
Maybe my new role will at some stage allow me to resurrect this blog under a new name but that may be some time.

Derek

Automatic Maintenance Mode after Windows Update

2009-12-08T09:41:00.002Z

Nice work by J. Greg using the Agent Maintenance Mode MP to do Automatic Maintenance Mode after Windows Update

Permissions Required for Agent Maintenance Mode

2009-11-25T15:06:00.003Z

I had a few emails regarding the Agent Maintenance Mode not working for some. It appears that there are a few reasons for this not to work correctly:

1. System Center Essentials 2010 that uses Opsmgr 2007 R2 but they have still don’t include the powershell support (Thanks to Bjorn Axell for this info)

2. The Default Action Account on the RMS must be a member of the Operations Manager Administrators Group. If you configured the action account by using Local System or a user that is not part of the Operations Manager Administrators Group, the script will not work.
This is a standard configuration for several MPs including the Opeartions Manager MP and the Active Directory MP.

New Agent Maintenance Mode

2009-11-18T01:36:00.011Z

Here is a new version of the Agent Maintenance Mode MP. This version is only for OpsMgr R2 as it leverages the new powershell modules only available in R2.

--Update--
Read this post if this is not working for you -Permissions Required for Agent Maintenance Mode
The readme has also been updated with this info
----

To recap on this solution:
It allows you to start Maintenance Mode from an monitored server using just a vbscript. Using this requires absolutely no permissions in Operations Manager. All of the components required to have this function are part of a standard OS with an agent installed. It works through Gateways so can be used in firewalled or untrusted environments.

The MaintMode.vbs writes an event to the event log that indicates the length of time Maintenance Mode should remain on. This is picked up by the management pack and processed on the RMS to turn on Maintenance Mode for that server. The on time can be specified in days, hours or minutes.

Download here

The zip file contains a Readme with more information and usage instructions.

Highligh of changes in this version:
Management Pack Changes
* Added Powershell modules in MP (R2 feature) to replace scripts on RMS. Some logic reworking in scripts
* Support for Server 2008
* Fixed ON/Off logic to not put Health Service and Health Service Watcher in to Maint Mode as R2 puts HS and HSW in to MM automatically
• Added Maint Mode event collection rules
• Added Schedule Maint Mode text file option at C:\MaintenanceModeSchedule.txt - origional by Steve Rachui - http://blogs.msdn.com/steverac/archive/2008/12/09/maintenance-mode-by-config-file.aspx
* Disables discovery on RMS as Maintenance Mode should not be used on RMS

MaintMode.vbs
* Now logs the username in the event log of who turned it on: “Maintenance Mode: ON for 6 hour(s): 360 . Turned on by domain\user”
* Adds registry markers to indcate current status under HKLM/Software/OpsMgr/Maintenance Mode. Can be used by patching tools.
* Added STATUS option that reads current status from registry.

Port Monitoring from a text file

2009-08-25T12:44:00.010+01:00

This is another solution on how to make something that requires permissions and experience in OspMgr available to everyone to use. Teach a man to fish and all that.

These two Management packs will allow any user you specify using simple NTFS permissions to add port monitoring for a server, network device etc.

Usage

Download and Import the 2 management packs:

On each management server a discovery in the AgentlessAvailabilty MP will create a text file C:\AgentlessMonitoring\resource.txt

You can add entries to this file in the format:
{name or IP address}, port - (comma seperated)

If no port is specified it will default to port 445.
Use the hash # at the start of a line to insert a comment.

The discovery runs every 1 hour. After the discovery runs any entries in the file will then display in the console under the standard Synthetic Transaction folder
Each entry will be checked every 10 minutes.

These MPs simply reuse the existing Port Monitoring template so there is a full range of specific alerts, health states and associated Knowledge articles

To make this so that anyone can use it simply share the C:\AgentlessMonitoring folder giving write permissions to those who need it

Technical Details

The sealed Custom.PortMonitoring.Library is essentially the Port Monitoring template with the module types having any specific information promoted to class properties. The discovery in the unselaed Custom.Infra.AgentlessAvailabilty MP then creates class instances with the necessary properties.

You can leverage the sealed MP from other management packs to add port monitoring. All it takes is writing a discovery.

How to upgrade or apply a hotfix to a Clustered RMS

2009-04-17T15:57:00.002+01:00

We have had a some difficulties over the months trying to apply hotfixes to any clustered Root Management Server. The hotfix installers try and stop the 3 OpsMgr services, apply the hotfix and them restart the services. These steps result in some unexpected behavior on a Clustered RMS.

What I have seen is that after the hotfix installer stops the RMS services the Cluster Service will try and restart them again.

This results in either the services running on the node you are trying to patch or the RMS resource group failing over. If the RMS fails over then, when the hotfix tries to restart the services after it has completed, it either times out or you have the RMS services running on both Cluster nodes. It it restarts the service on the node you are trying to patch the install will fail as the files are in use.

Here are some steps that can avoid these issues:

1. In Cluster Administrator ensure the RMS resource group is on the node you are patching. Then Pause the Node you are not patching. Simply right Click on the node and select Pause. This stops the resource group failing over to the other node.

2. Set the 3 RMS services not to restart automatically. Selecting each service, right Click and select Properties. On the Advanced tab set it to "Do not restart"

3. Apply the hotfix to the current node

4. When the hotfix has completed reset the services to restart automatically and resume the other node.

Repeat this to apply the patch to the second node.

This process also worked for me in upgrading a clustered lab environment to the Release Candidate of R2

Operations Manager Data Warehouse High CPU Utilization

2008-12-05T10:55:00.003Z

Some good steps if you are having trouble with CPU on your DW.

http://www.afinn.net/2008/10/operations-manager-data-warehouse-high-cpu-utilization/

Data Warehouse Queries for Noisy Rules

2008-10-09T12:29:00.004+01:00

Here are a few SQL queries that you can run on the Operations Manager Data warehouse to determine what are the Noisy Event and Performance rules in your enviroment.

Noisy Event Rules

select count(*) as cnt, RuleDefaultName
from Event.vEvent as ev
Left Join Event.vEventRule as evi
On ev.eventOriginID = evi.eventOriginID
Left Join vRule as r
On r.RuleRowId = evi.RuleRowId
group by RuleDefaultName
order by cnt desc

Noisy Performance Rules

select count(*) as cnt, RuleDefaultName
from Perf.vPerfRaw as pr
Left Join vPerformanceRuleInstance as pri
On pr.PerformanceRuleInstanceRowId = pri.PerformanceRuleInstanceRowId
Left Join vRule as r
On r.RuleRowId = pri.RuleRowId
group by RuleDefaultName
order by cnt desc

As expected, in a few enviroments I tested, some of the busiest performance rules were the Processor and Memory collection rules.

However there were several unexpectedly busy Event rules that accounted for a significant portion of all the event data and some of these were subsequently disabled.

Thanks to Reut for pointing me in the right direction for the initial query.

Speed up Command Shell startup

2008-10-08T12:51:00.002+01:00

There is a post over on the Powershell team blog about how to speed up Powershell startup times. I ran this on a few of my Operations Manager Servers and it noticeably made a difference to Powershell startup times. However the Operations Manager command shell was still quite a bit slower.

I then ran the same script from within the command shell and it found something to NGEN

NGENing : Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll

In my very scientific way of couting seconds in my head before and after running this it definitley starts faster.

Check it out - http://blogs.msdn.com/powershell/archive/2008/09/02/speeding-up-powershell-startup-updating-update-gac-ps1.aspx

Clearing Console Cache and User Settings

2008-10-03T15:14:00.002+01:00

There are a few steps to be taken to really clean up a console if you have performed some personalization.

Open regedit and delete the key HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console

Start the Operations Console from the command line with the option /clearcache

Example:

C:\Program Files\System Center Operations Manager 2007\Microsoft.MOM.UI.Console.exe" /clearcache

Useful methods for searching MP's

2008-10-03T14:08:00.008+01:00

Usually when i am looking for a way to do something in a management pack I refer to the Microsoft MP's as it has likely been done in them. Here is my normal process for searching these MP's.

In my development environment I dump all the management packs out to their XML. This is done using Command Shell.

mkdir c:\unsealed
get-managementpack | export-managementpack -path C:\unsealed

Then I open Notepad++ with the XML Tools plugin installed. A fantastic function of Notepad++ is Find in Files...

So say I am looking for the syntax to use in a recovery to start a service. I can Open up Notepad++ and do a Find in Files and look for "net start"

A few comments I read on the OpsMgr newsgroups about the Agent Maintenance Mode solution that I posted pointed out that the %MOMROOT% variable was not on the path and could not be used from the command line. If you do a search across all the MP's using the methid above it is defined in several different ones ( Sharepoint 2003, System Center Core Management Pack). Looks like this is something defined only within the context of OpsMgr.

All my failed Power supplies using Powershell

2008-10-01T14:48:00.003+01:00

Sometimes you just want to see all the systems that have a certain problem, like failed power supplies or all systems where free disk space is low.

Here is a bit of Powershell to list any server where the Health State of the HP Proliant SNMP Management Pack Power supply Class is in an Error state.

$ClassID = "HewlettPackard.Servers.ProLiant.SNMP.HPProLiantSNMPPowerSupplies"
$Class = get-monitoringclass -name:$ClassID
$ClassInstances = get-monitoringobject -monitoringclass:$Class
$Errors = $ClassInstances | where {$_.HealthState -eq "Error"}
Foreach ($Server in $errors)
{
$server."[HewlettPackard.Servers.HPHealthCollection].ServerName"
}

Free Space /Availability of Logical Disks on Server 2003

$ClassID = "Microsoft.Windows.Server.2003.LogicalDisk"
$Class = get-monitoringclass -name:$ClassID
$ClassInstances = get-monitoringobject -monitoringclass:$Class
$Errors = $ClassInstances | where {$_.HealthState -eq "Error"}
Foreach ($Server in $errors)
{
$Server.Path + "," + $Server.name
}

A good way to catch issues where the alerts may have been missed.

Of course you can just use the Discovered Inventory View on the Operations Console and change the target type to Windows Server 2003 Logical Disk but the console has no easy way to get this data out except a one by one copy and paste.

Hp Storageworks Management Pack

2008-10-01T13:18:00.005+01:00

I had a quick look at the Hp Storageworks MP v1.5 for the first time today and noticed quite a few glaring issues.

There are 5 separate discoveries running every 60 seconds on ALL computers. Looks like someone forgot to change the interval on these after development was finished. At least it is possible to change these intervals using overrides.

The discovery "HP StorageWorks SNMP Trap Catcher Discovery Rule" discovers every system with the SNMPTRAP service installed. Then proceeds to start monitoring all these servers. This monitoring includes an WMI query that runs every 15 seconds on all the servers that have the SNMPTRAP service and runs a script every time!!

The WMI query rule is using the backward compatibility layer so the interval cannot even be overriden.

[Off Topic] - The EOL Monster

2008-09-25T22:04:00.003+01:00

Some stuff that has been hanging around the office for a few years.

Quick Access to OpsMgr Agent Information

2008-08-14T14:52:00.008+01:00

Sometimes you need access to some information from Opsmgr in a hurry and you really do not want to open up the Ops Console and wait for it to load.

Here is a powershell script that extracts information from OpsMgr and drops it into several HTML files so it can be added to a website.
Download Script

The pages created are the following

AgentsCounts.html - This gives give you a count of the number of agents per management group and breaks this down also by per management server

MonitoredServers.html - This page gives a complete list of all the agents being monitored by Opsmgr.

ServersDown.html - This gives a list of servers that may be down. It is actually a list of servers where the health service watcher is in an "Error" state.

AgentsLast7days.html - This is a list of all agents installed in the last 7 days, when they were installed and includes their health state

The script does require some configuration before it can be used:

1) At the very start of the script you have to enter the name of the Root Management Server. You can uncomment the next lines lines and define multiple RMS's if you want to pull the information from more than 1 management group.

2) $outpath = "c:\" - Change this to where you want the script to write the html files.

3) If connecting to more than one management group you need to comment out line 17 and uncomment Line 19

Updated Agent Maintenance Mode

2008-08-12T00:23:00.008+01:00

---Update---

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

---------

There is a new version of my Maintenance Mode MP and scripts that can do maintenance mode from the Agent with no extras installed (The original post is here). The 4 files are available for download from http://cid-397bb61b75cc76c5.skydrive.live.com/browse.aspx/Public/AgentMaintModeV2?view=details

-----------

EDIT

Be aware the PowerShell execution policy might block the script from being run.

You may need to do the following:
1. Open the Command Shell, and do "set-executionpolicy remotesigned" (using "allsigned" may be considered a bit more secure.
2. Right-click on the .ps1 files, chose properties and click "Unblock" especially if you've downloaded these scripts using Internet Explorer.

Thanks to Marco for catching this. I had a few people contact with with the earlier version not working and I could never figure out why. Could be the same reason.

----------------

This version adds the ability to turn off maintenance mode from the agent as well as turn it on. The vbscript has been updated with some more options and some instructions on how to use it.

To install or update you need to import the management pack and copy the 2 ps1 files to System Center Operations Manager 2007 program folder on the RMS.

Then you need to copy the vbscript file to any agent managed server and run it to set any server in maintenance mode for the desired time period.

------------------------------

VBScript Usage:

Usage: MaintMode ON|OFF [ON Duration][D][H][M]

Examples: MaintMode ON 6H
MaintMode ON 2D

ON is a mandatory keyword to put a server in maintenance mode.

ON Duration is number of [D]ays [M]inutes or [H]ours Maintenance
Mode should remain ON.

If not specified, the default is 6 hours.
This means Maintenance mode will turn itself OFF after 6 hours.

If ON Duration is specified without [D][H][M], the number is
interpreted as hours.

------------------------------

This MP creates a new class which contains all Windows Operating Systems. There are 2 rules in this class. One listens for the Maint Mode ON event and the other listens for the Maint Mode OFF event. The script on the RMS that turns on Maintenance Mode actually turns it on for all the components of the server and then turns it off again only for the Maint Mode class. This means that even in Maint Mode it can listen for the OFF event.

NOTE: The discovery for this class runs every 12 hours so be aware that systems may take this long after install for the scripts to work

Thanks again to Boris for his examples and scripts for doing maintenance mode.

Multiple Network Name Discovery in a Cluster Resource Group

2008-05-27T10:29:00.001+01:00

There is a known bug in OpsMgr that when you have more than one network name in a cluster resource group only the first one is discovered - http://support.microsoft.com/kb/919594. So say, for example, a cluster is not configured according to best practices and the MSDTC resources and the SQL resources are in the same group. You have a network name called "MSDTC Network Name" and one called "SQL Network Name ...". In this case the MSDTC network name will be discovered and the SQL Network name will not be discovered.

What's the problem with this exactly? Well, if the SQL Network Name is not discovered then the SQL instance in this resource group will not be monitored by the SQL MP.

To determine if you have clusters with this problem you can download and import the following MP - ClusterError.xml

It will create a view in your Operations Console that will list all the clustered servers that have more than 1 network name in a resource group.

Initiate Maintenance Mode from an Agent (no extras installed)

2008-02-19T15:33:00.006Z

---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

2008-02-18T15:58:00.003Z

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

2007-12-07T11:07:00.000Z

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

2007-11-29T09:41:00.001Z

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

2007-09-26T14:57:00.002+01:00

- 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 "& '$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

2007-09-25T08:53:00.000+01:00

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.

2007-09-11T20:28:00.000+01:00

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$

Active Directory Agent Assignment using a database

2007-08-09T10:25:00.000+01:00

The post over on System Center forum about Using Property Bags with Custom Scripting in Operations Manager 2007 has helped me to solve a problem I was having with doing Active Directory based Agent Assignment using a database. This is for integration with a CMDB type database to control agent assignment.

This will take the form of a rule that runs a script to query a database and returns multiple property bags with each property bag containing the dnshostname and distinguished name of each computer that is to be assigned to a management server.

The output fo this script can then be passed to the AD writer action that writes the computer objects to the relevant security groups in the management group OU under the Operations Manger OU.

The rule that is generated by the GUI using the LDAP provider to perform the LDAP query and returns a result for each object found and passes each result seperatley to the Ad Writer rule. This is where the multiple property bags comes in as the of the AD Writer action expects multiple inputs that can only be provided, as far as I can determine, by using multiple property bags.

The rule will run on each management server and the script will simply query the database for the agents belonging to that management server. All the load balancing will be done by the database itself.

I will be have more on this rule in future posts.

More about Property bags and Varant types

2007-07-19T12:18:00.000+01:00

When returning values in a property bag that are not string values you will have to break open the XML of the management pack to be able to compare the values correctly.

The XML generated by the Authoring console will look something like:

<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="String">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>

If returning Integer values that you want to compare with integers you will have to change it to:

<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type="Integer">Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="Integer">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>

Note that the Type declaration has to be on both sides of the expression. Also be aware that some version of the Authoring console may strip the Type="Integer" from the XPath query.

Thanks to Alexandre Coelho for this fix.

Passing an Event Description to an Alert description

2007-07-18T19:01:00.000+01:00

Finding the correct Data Item Context Parameters to use in Operations manager can be a problem. Here is the one to pass an Event description to an Alert. Useful if you want the Alert description to contain the Event description.

$Data/Context/EventDescription$

Export a Sealed MP

2007-07-17T11:20:00.000+01:00

Export a Sealed MP

A sealed MP can be exported to an XML file using Command Shell.
Find the correct name of the MP you want to export using:

get-managementpack | where {$_.Name -like "*Server.2003"}

Export using:

get-managementpack | where {$_.Name -eq "Microsoft.Windows.Server.2003"} | export-managementpack -path C:\MP

Property bags and Variant Types

2007-07-16T23:13:00.000+01:00

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

Clearing the Operation Manager Console Cache

2007-07-16T16:51:00.000+01:00

When creating and deleting management packs you may find that the console becomes out of sync with the database. To fix this you can delete the Console cache by deleting the files under
C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\Microsoft.Mom.UI.Console

Some Ops manager Agent Stuff

2007-07-13T11:55:00.000+01:00

We had some problems every time we built a new management group in our lab. All the old agents would still be trying to report to the old management group. This was a pain because all this did was clutter up the Operations Manager Log. The solution we used was to create a task that would completely uninstall all the agents. They would then be automatically reinstalled by the active management group if you have applied the overrides to enable the recoveries as detailed in the System Center Management Pack Guide. A bit of powershell would then run this task against all agents.

To Create the Uninstall Task

On the Authoring pane on the console create a new command line agent task called CompleteUninstall. The target is Windows Computer. The command line settings are shown below.

Uninstall command for Agent (RTM)

MsiExec.exe /x {E7600A9C-6782-4221-984E-AB89C780DC2D} /quiet

This gives us a task that ca be run on an agent to perform an uninstall of an agent. To run this on all agents the easiest way is to do it in a powershell script

Powershell Script to run the task for all agents

$uninstallTask = get-task | where {$_.Name -eq "CompleteUninstall"}
foreach($agent in get-agent)
{
$server = $agent.Displayname
$server
start-task -asynchronous -task:$uninstallTask -path .\Microsoft.SystemCenter.AgentManagedComputerGroup\$server
}

Save this script as a .ps1 file and then run it from the Operations Manager Command Shell. The results of these tasks will always show in the Operations Console under Task Status as failed as the Agent has been removed.

Operation Manager Command Shell on any system

2007-07-12T14:18:00.000+01:00

This is a basic guide to get a Operations Manager Command shell on any system without having to install the UI components. You will need to have Powershell and DotNet 3.0 installed on the system.

Copy the Files

You will need to copy some files from your Ops manager install to get the command shell working.

From the Ops Manager installation directory:

Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll-help.xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml

From the SDK Binaries Folder in the Ops Manager installation directory:

Microsoft.EnterpriseManagement.OperationsManager.dll
Microsoft.EnterpriseManagement.OperationsManager.Common.dll

Copy these files to a folder on the system you want the command shell on. For this example I will copy them to C:\OpsShell.

Register the Powershell Snap-in

For the Powershell snap-in to work we need to register it. As we are not installing the UI this will have to be done manually. Add the below registry settings replacing "C:\\OpsShell" in the following regsitry entries with the correct path to the files.

-----------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.EnterpriseManagement.OperationsManager.Client] "ApplicationBase"="C:\\OpsShell" "AssemblyName"="Microsoft.EnterpriseManagement.OperationsManager.ClientShell, Version=6.0.4900.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" "ModuleName"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.dll" "PowerShellVersion"="1.0" "Vendor"="Microsoft Corporation" "Version"="6.0.4900.0" "Description"="Microsoft Operations Manager Shell Snapin" "Types"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Types.ps1xml" "Formats"="C:\\OpsShell\\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Format.ps1xml"

-----------

Create the Startup Script

Below is a Powershell script that you can use as a shortcut to start the Command Shell. Copy it to notepad and save it in C:\OpsShell as OpsShell.ps1. Some of the script was borrowed from here

-----------

param ($rootMS)

$rootMS.Length
if ($rootMS -eq $null)
{
$rootMS = Read-Host "Root manangement server"
}

$checksnappin = Get-PSSnapin | where {$_.Name -eq "Microsoft.EnterpriseManagement.OperationsManager.Client"}
if ($checksnappin -eq $null)
{
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
}
Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin ;
set-location $rootMS -ErrorVariable errSnapin ;

-----------

Starting the Command Shell

To start the Command Shell open powershell and run C:\OpsShell\OpsShell.ps1.

If you get the error:

File C:\OpsShell\OpsShell.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.

Then run this command to change the execution policy:

Set-ExecutionPolicy Unrestricted

This works for me on XP SP2 and Server 2003 SP2

This could be expanded to offer the ability for our server admins to do things such as set Maintenance Mode on or off without having to do it in 3 different locations in the console as is currently needed.