locked
KHI: IMAP4 connectivity transaction failures RRS feed

  • 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 Corporation
    Thursday, 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 Corporation
    Thursday, 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 Corporation
    Monday, 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 Corporation
    Tuesday, 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?


    Stew
    Wednesday, 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