April 15, 2014 at 10:57 am
I configured alerts for severity alerts 016 through 025 as well as error numbers 823, 824 and 825 on our servers. I'd like to leave these running, but today I temporarily disabled the alert for 020 because I had several e-mail messages for SSPI handshake failures (one every minute for over 40 minutes before I disabled the alert):
DESCRIPTION:SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: xxx.xxx.xxx.xxx]
I'm not sure the underlying cause, though I'd suspect someone was forced to change his/her password today and had not yet updated whatever tool they have connected to the server. At any rate, I see a checkbox option to "raise alert when message contains" some string value, but what I'd really like is the opposite - "raise alert when message DOES NOT contain" some string value. Is there any way to filter these messages out? I'd like to leave the alert active but I really don't want my inbox being flooded when a user fails the SSPI handshake.
I guess I can set up a rule in my mailbox, but so would any other operators that receive the notification. I'd prefer to filter it at the server level if possible.
Andrew
--Andrew
August 18, 2016 at 4:14 am
Did anyone manage to solve this?
I have a similar problem. Our infrastructure team has an Intrusion Detection System and every time it is run I get alert 020 from all 37 of our SQL instances which is somewhat annoying. I would like to filter these alerts so they ignore the IP of the Intrusion Detection System client.
Does anyone have any ideas?
August 18, 2016 at 6:32 am
I certainly haven't. So far I just have a rule on my mailbox that diverts those to a folder. At least that way I still get them and can review them when I want but don't get flooded by new message alerts on my phone when they come in.
I also have a similar situation to yours. Every Wednesday afternoon I get two messages where an enterprise scanning package hits one of our test database servers. One is attempting to create a second connection to the DAC and the other is an intentionally malformed packet that is being blocked. Neither "attack" succeeds but I still get the messages every week. (Also curious, this is the only server in our data center that reports these errors. None of them are published including this one, so it's odd that they attempt to exploit it on this one but not the others.)
--Andrew
August 18, 2016 at 6:57 am
Thanks for your reply.
It could be the same software as I get those two messages from all 37 instances. Ours seems to run once or twice a week out of main office hours.
I will play with my mailbox rules to see if I can stop the messages flooding my phone - not the best thing when one has bleary eyes first thing in the morning!
October 26, 2017 at 9:31 am
I'd like the same and for exactly the same reason. Unless MS provides this necessary functionality, the only idea I can think of would be to fire a job and pass tokens into it that can be used to filter on. Tokens can be enabled in the Agent properties on the "Alert System" tab. In SSMS 2016 its the very last option on that tab.
Details on how to do this can be found here -https://docs.microsoft.com/en-us/sql/ssms/agent/use-tokens-in-job-steps
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply