Friday, March 30, 2012

connecting to sql from a remote host

ever install sql on a box and then you can't connect to it from a remote host?  you're trying to install a system center product and you're at the point where it asks where your sql server is and it's time to create some DBs... i've done this plenty of times and depending on whether you're installing an eval version or hosting all roles on a single machine, these settings can vary and can cause a headache.   here's a simple post of a few checks and solutions.



first, see if you can telnet over 1433 from the remote host to the sql server (telnet SQL-IP 1433).  if you can do this, then chances are you aren't reading this :)

what i usually do at this point is RDP directly to the sql server and open the sql server configuration manager.  assuming you're on x64, drill down on the left-side to sql server network configuration and open the protocols for your instance.  this will be mssqlserver if you chose the default instance but could be anything if you chose the named instance.  i'm using sql server 2008 r2 eval and have a named instance of vmm since that happens to be the toy of choice tonight.  ensure that tcp/ip and shared memory are enabled.  open the properties for tcp/ip and click on the ip addresses tab.  this is the important part - ensure the following:

active: yes
enabled: yes
ip address: x.x.x.x
tcp dynamic ports: - must be blank to signify you want it disabled
tcp port: 1433

at the bottom for IPall:

tcp dynamic ports: must be blank to signify you want it disabled
tcp port: 1433

on the protocols tab ensure that enabled and listen all are set to yes, click ok and then restart the sql service.


now, see if you can telnet... betcha can.

Thursday, March 15, 2012

exchange 2010 management pack: guidance, tuning and known issues

i just ran across this today and it's a world of help for any scom admin working with the exchange 2010 mp.

http://support.microsoft.com/kb/2592561

in particular there's a tidbit about modifying the alert severity and priority - something i've been trying to figure out for a while but with all the conflicts posts, i just gave up (hence my last post).  well, this kb article reinvigorated the thought that it COULD be done, and sure enough, c'est fini!

how to override the alert severity or priority for an alert in the exchange 2010 mp-
the trick is that because of the correlation engine, you have to target the rule towards the root management server class (since that's where the correlation engine resides).  i've read articles where they say it's a bad idea to modify any rules and to only modify the monitors - but modifying the monitors doesn't work and modifying the rules does - so... yea.  if anyone has any insight as to whether or not i'm committing a sin by overriding a rule, then please enlighten me.

find which alert you want to change the severity or priority for:

right-click any of them > overrides > override the rule > for all object of another class...

choose root management server and click ok (not shown because i'm lazy)

in my case i want this alert (which is normally critical) to be informational.  so i set the severity to 0 (use the table below for other options).  notice the override target is the root management server class and i've saved this off to my exchange 2010 overrides mp.



Severity:



Critical
2

Warning
1

Information
0
Priority:



High
2

Medium
1

Low
0

and... wa-lah!  after resetting the health from the health explorer on that specific DB and closing the alert, then just wait a few minutes and when the alert triggers again it'll be informational.

this will also help in filtering out specific alerts so they don't create tickets in service manager if you only allow "warning" and "critical" alerts to create IRs in service manager.




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!