Showing posts with label service manager. Show all posts
Showing posts with label service manager. Show all posts

Wednesday, March 14, 2012

how to exclude specific alerts from the scom alert connector

recently i was working with our ad & messaging team trying to fine-tune the exchange alerts and it came up that the team wanted to receive e-mail notification from scom re: some of the alerts but didn't want those same alerts sent to the scom alert connector to be created as tickets in service manager.  at first i thought this would be impossible and was toying with the idea of using orchestrator to do something fancy, but couldn't even come up with a solution using scorch.


after posting to the forums, i was able to get some good feedback and help with a solution.  here is that solution:


at a high-level we're going to go old school before scom had detailed alert subscriptions in the UI.  we're going to export the unsealed notifications internal library mp from scom.  edit the xml to exclude some specific alerts by RuleID.


first let's determine which alert(s) we want to exclude.  a quick glance at the existing exchange 2010 alerts shows a plethora that we'd ideally like to demote to "informational", but thanks to the correlation engine, this isn't possible :( keep in mind we use the scom alert connector in conjunction with service manager so all these alerts create IRs in service manager and our end goal is to only receive an e-mail notification from scom - but not create an IR in scsm.






to find the ruleID - open any of the alerts and switch to the "alert context" tab.  scroll to the bottom and you'll find the ruleID.  copy the ruleID.




next, from the scom console, go to the administration pane and open management packs.  find the notifications internal library and export it.  use something like notepad ++ to edit the xml.


first we need to find the product connector subscription.  if you scroll to the bottom of the xml, you'll start to see familiar subscription names.  note: this mp can have thousands of lines (mine has 35,600+).  it'll ultimately depend on the number of subscriptions you have in the environment.


normal email subscriptions created in scom will have an elementID similar to this:



subscriptions in the scom alert connector will have en elementID similar to this:



in my case I want to exclude alerts created by the exchange mp so i'm going to modify the section of the subscription that relates to that.  i copy the above elementID for Exchange and do a find in the current MP to see where else it shows up.  note: only copy ProductConnectorSubscriptione5a1d162_0280_4951_9453_df0910f956eb - not the text before or after it.


you should only find it in one other place.
scroll down past all the groupIDs and typeIDs.  you'll eventually arrive to the beginning of the criteria section and the expressions.  this is where you want to be.  for best practice i comment out what exactly my customizations are.  after the criteria, expression and and tags, i add my own expression which will exclude the specific ruleID i found above.




notice the property is RuleId, the Operator is NotEqual and the Value is the value of the RuleID we found above.  if you have more than one exclusion, you just keep adding like this:



an important note:  once you edit the XML section of the productconnectorsubscription, you cannot modify it via the console again or else it'll wipe out your customizations.  here's some testing i did to better illustrate this:

Created a new exchange e-mail subscription in the scom console - kept the custom logic

Created a new subscription on the scom alert connector (alertsync) - kept the custom logic

Modified the e-mail scom subscription by adding a rule - kept the logic

Modified the exchange scom alert connector subscription - removed the logic





basically, if you modify the Exchange subscription via the GUI shown above, you'll lose the custom logic for excluding the alerts.  so, definitely back the file up once you've got it right and then in the future, if you want to make modifications to it via the scom console, just make sure you have that backup so you can transplant the custom XML after you've modified it via the scom console.  hope this helps!


another good resource is here.



Thursday, February 23, 2012

how to remove a SCOM CI Connector from Service Manager (not supported by Microsoft)

so this is by no means microsoft supported but after doing this and then using the environment for 6+ months i can safely say that we have had no negative side effects of this.

this procedure removed the "stale" SCOM CI Connector from the SCSM console.

first i found the BaseManagedEntityId that is associated with the connector.  in my case this ended in 1558D.  so my delete SQL queries included where [tablename] like '%1558D%'.

these are the tables where the SCOM CI Connector resides:
Dbo.MT_Connector - deleted SCOM Alert Connector  (1558D)
Dbo.connector - deleted BaseManagedEntityId ending in 1558D
Dbo.recursiveMembership - deleted ContainedEntityID ending in 1558D
Dbo.BaseManagedEntity - deleted BaseManagedEntityId ending in 1558D

i think there's a stored proc you can run after this which will clean things up, but i don't know it off the stop of my head.  you can also just wait 24 hours i believe...

happy deleting!

Monday, November 28, 2011

Add Affected Items to the Title or Description of a Service Manager IR

I recently began creating Incidents in Service Manager from alerts created in Operations Manager via the SCOM Alert Connector.  I'm pushing this out slowly to the various groups (SQL, Windows Server, App Support, etc...) so I can pay more attention to each one as I roll it out and do some hand holding.  The SQL group was welcoming of it last week, but requested that the Affected Item(s) show in the Title of the Incident so they can quickly see (either via the e-mail notification or in the console) which server or DB was affected because otherwise you have to open the ticket and scroll down and you might end up with a situation like this:


I know a DB is offline, some IS Packages failed, etc... but considering I have thousands of DBs and many packages... this view doesn't really help me if I want to quickly identify which DB is offline.

I reached out to Travis and asked him how to do this.  He responded with this blog post which says it's not possible natively within Service Manager because the max cardinality for those relationships can be > 1.  More info here: http://blogs.technet.com/b/servicemanager/archive/2011/04/06/faq-why-can-t-i-add-some-columns-that-i-want-to-views.aspx.

At a high-level, here is how I solved this and here's the policy I created in Opalis specifically for the SQL team.  
  1. Use Monitor Object to look for newly created or updated IRs
  2. Get the relationship between the object GUID returned from Monitor Object and whatever class you're looking for.  In this case, I chose Windows Computer class.
  3. Query the ServiceManager DB to match the GUID of the Affected Item to it's Principal Name
  4. Repeat steps 2 and 3 for other classes such as SQL DB Engine or SQL Database
  5. Update Incident
Since depending on what alert is thrown, it's going to use items from different classes, you might need to add many get-relationship and query sql objects.  In my example, I've added three since for the alerts we receive, they seem to all involve three classes.
  1. Windows Computer
  2. SQL DB Engine
  3. SQL Database
Here are the screenshots from the first 3 objects and then the last one:



To query the SQL DB Engine, you'll need this:
USE ServiceManager
SELECT [AgentName_69B79706_8AE1_470D_5FD7_0AAA7A126CCA]
FROM [ServiceManager].[dbo].[MT_Microsoft$SQLServer$DBEngine]
WHERE BaseManagedEntityId = 'Related Object Guid from...'

For SQL Database:
USE ServiceManager
SELECT [DisplayName]
FROM [ServiceManager].[dbo].[MT_Microsoft$SQLServer$Database]
WHERE BaseManagedEntityId ='Related Object Guid from...'

You'll just have to use SQL Management Studio and dig inside the Service Manager DB to find which table and column you need to query depending on the object.


Now when a new IR comes through, the policy will run and the Title will look like this:


If you rather, you can update the Description field or both.  Just add or modify the Fields section in the Update Object Properties.

Tuesday, August 2, 2011

getting vmware components to show up in service manager

if you have quest's qmx xtensions for vmware monitoring, it's easy to get that information into service manager so you can report on those components.

once the scom ci connector is setup, you'll need to import the sealed eXcSoftware.nonWindows MP (mine is version 7.0.0.23).  once that is imported you'll need to import the Network Device Library MP.  once that is imported you can then import the unsealed QMX.VMWare MP (mine is version 7.0.0.19).  they must be done in this order.


once the MPs are imported, you'll need to allow those classes:
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.WindowsProxyComputer
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.AVAILABILITY
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.CONFIGURATION
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.CPU
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.DISK
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.FAN
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.MEMORY
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.NETWORK
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.POWER
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.PROCESS
add-scsmallowlistclass -ClassName eXcSoftware.nonWindows.nonWindowsObject.SECURITY
add-scsmallowlistclass -ClassName QMX_Monitor_VMWare_OpsMgrMP.Group

open the scom ci connector > click on management packs and refresh.  type in your account password for the connector and eXcSoftware.nonWindows and QMX_Monitor_VMWare_OpsMgrMP should now show up.  put a checkbox next to those and click 'ok'.

keep in mind, if you use the free version of QMX for VMware then ONLY your vCenter host will show up (not the ESX hosts or guests).  in my case i'm also monitoring some IronPort's so those show up as well.  if you want all the ESX hosts to show up then you need to get paid licenses for EACH ESX host ~ costly.