Answered by:
KHI: IMAP4 connectivity transaction failures

Question
-
This rule does not handle overrides or being disabled for objects. I have tried every way i can and it still comes back. It's like the uncle no one likes.
Daren
Thursday, September 16, 2010 1:11 PM
Answers
-
Hopefully this will help--we had the exact same issue because we don't use IMAP4. We stopped it by override-disabling this monitor targeting IMAP4:
KHI: IMAP4 connectivity transaction failures.
Initially we had overridden the KHI alert rule, but were then informaed overriding the KHI rules could make the correlation engine work harder, so it made sense to kill the monitor causing the state changes that are then evaluated by the correlation engine. We did the same thing for POP. Our understanding is there is a new 2010 MP being tested now, and hopefully this one is more forgiving and less punishing to the RMS in a larger environment.
--Drew
- Marked as answer by Dan Rogers Friday, September 17, 2010 3:30 PM
- Unmarked as answer by Daren Daigle Monday, September 20, 2010 2:26 PM
- Marked as answer by Daren Daigle Wednesday, September 22, 2010 2:09 PM
Thursday, September 16, 2010 7:45 PM
All replies
-
What MP is it from? Is there someone else whom you share management group administration rights with?
Microsoft CorporationThursday, September 16, 2010 3:40 PM -
What MP is it from? Is there someone else whom you share management group administration rights with?
Microsoft Corporation
Duh! Exchange 2010 MP. Others share rights with me but I do 99% of the administration.Thursday, September 16, 2010 3:51 PM -
Sorry - there is an awful lot of alphabet soup around here (ALASL:AH)
A lot of the exchange 2010 behaviors are not controlled by the operator -what is it about the alert or symptom you are seeing that makes you want to disable checking this transaction path?
Microsoft CorporationThursday, September 16, 2010 4:04 PM -
Hopefully this will help--we had the exact same issue because we don't use IMAP4. We stopped it by override-disabling this monitor targeting IMAP4:
KHI: IMAP4 connectivity transaction failures.
Initially we had overridden the KHI alert rule, but were then informaed overriding the KHI rules could make the correlation engine work harder, so it made sense to kill the monitor causing the state changes that are then evaluated by the correlation engine. We did the same thing for POP. Our understanding is there is a new 2010 MP being tested now, and hopefully this one is more forgiving and less punishing to the RMS in a larger environment.
--Drew
- Marked as answer by Dan Rogers Friday, September 17, 2010 3:30 PM
- Unmarked as answer by Daren Daigle Monday, September 20, 2010 2:26 PM
- Marked as answer by Daren Daigle Wednesday, September 22, 2010 2:09 PM
Thursday, September 16, 2010 7:45 PM -
Sorry - there is an awful lot of alphabet soup around here (ALASL:AH)
A lot of the exchange 2010 behaviors are not controlled by the operator -what is it about the alert or symptom you are seeing that makes you want to disable checking this transaction path?
Microsoft Corporation
It's simple. I do not RUN imap4 on any of my CAS servers and my own CAS array uses POP3. So I have a few POP3 alerts similarly showing. I tried changing overrides or disabling things and they keep coming back like the energizer bunny.Thursday, September 16, 2010 8:48 PM -
Hi,
Regarding the rule, I got the following information:
IMAP4 connectivity transaction failures.
http://technet.microsoft.com/en-us/library/bb974219(EXCHG.140).aspx
Please check if you can find it in SCOM console and override it:
How to Disable a Monitor or Rule Using Overrides
http://technet.microsoft.com/en-us/library/bb309583.aspx
Hope this helps.
Thanks.
Nicholas Li - MSFT
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Friday, September 17, 2010 8:31 AM -
Hi,
Regarding the rule, I got the following information:
IMAP4 connectivity transaction failures.
http://technet.microsoft.com/en-us/library/bb974219(EXCHG.140).aspx
Please check if you can find it in SCOM console and override it:
How to Disable a Monitor or Rule Using Overrides
http://technet.microsoft.com/en-us/library/bb309583.aspx
Hope this helps.
Thanks.
Nicholas Li - MSFT
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
None of these work, either.- Marked as answer by Dan Rogers Monday, September 20, 2010 3:47 PM
- Unmarked as answer by Daren Daigle Monday, September 20, 2010 3:50 PM
Monday, September 20, 2010 2:26 PM -
Darren,
It looks like there is an answer from devwannabe that should do the trick for you.
Microsoft CorporationMonday, September 20, 2010 5:52 PM -
Darren,
It looks like there is an answer from devwannabe that should do the trick for you.
Microsoft Corporation
I know it does, but I override the monitor and I get another one later on and when I look at the summary and it shows disabled.Tuesday, September 21, 2010 3:11 PM -
One thought is to look at the discoveries that create the classes that these monitors target. If you disable the discovery (if possible to separate the IMAP classes) then this should stop. The challenge though will be getting them undiscovered since disabling a discovery causes it to NOT run again - so the classes will still exist. There is a script rolling around here that lets you undiscovery classes where the source discovery is disabled.
That's one thought.
Another is that it might not be possible - someone from Exchange would have to figure out what the limits are. If the monitors keep coming back I've never seen that behavior before. Is it possilble that the same server is in two override groups and your rules and someone elses overerride rules are colliding?
If there are multiple overrides, and one of them has "enforced" set to true, that one always wins.
Microsoft CorporationTuesday, September 21, 2010 3:56 PM -
Drew - which actual monitor did you disable in this case?
Ive found in the Exchange 2010 MP
IMAP4 Service > Entity Health > Availability > IMAP4 Service
and also
Services > Entity Health > Availability > KHI: The Microsoft Exchange IMAP4 service (MSExchangeIMAP4)isnt running.
was it one of these?
StewWednesday, January 19, 2011 2:11 AM -
Hopefully this will help--we had the exact same issue because we don't use IMAP4. We stopped it by override-disabling this monitor targeting IMAP4:
KHI: IMAP4 connectivity transaction failures.
Initially we had overridden the KHI alert rule, but were then informaed overriding the KHI rules could make the correlation engine work harder, so it made sense to kill the monitor causing the state changes that are then evaluated by the correlation engine. We did the same thing for POP. Our understanding is there is a new 2010 MP being tested now, and hopefully this one is more forgiving and less punishing to the RMS in a larger environment.
--Drew
Just a short question...
"Kill the monitor" means realy to "Disable the Monitor" instead of "Override the Monitor"???
Cheers,
Mike
Monday, March 21, 2011 2:33 PM