Lync MAPI Connectivity Into Exchange (UcMAPI.exe)

Hi Cory, that's unusual. APM can absolutely handle the RPC-over-HTTP traffic, since that's also what Outlook Anywhere uses.

You are saying that you see this error, but the MSRPC traffic from Lync does in fact authenticate successfully through APM?

It does. Authentication initiated through both the Outlook client and Lync's UcMAPI.exe process both seem to throw the errors into the APM log as they are both initiating connectivity to APM with a HTTP method of RPC_OUT_DATA. However, the session successfully passes Policy Evaluation and holds consistently throughout the entire usage of either client. All in all, this appears to be more of a cosmetic concern than anything functional.

On another note, we JUST upgraded to 11.5.3 HF2, so I'm wondering if we may be seeing some fallout from a recent bug fix. Perhaps this may not be related to the Exchange Profile/iApp and it could be a new finding.

I will continue to poke around today and see if I can find anything else.

-Cory

This appears to be a net new issue for some reason.

In our case, we are using the APM iRule to add persistence, and I have buried this iRule within a Universal Persistence Profile so we can enable persistence mirroring across our HA Pairs.

Now when we fire up a new client, an ADDITIONAL persistence record is created to Pool Member 127.20.2.254:10001 which I can only guess is some kind of internal proprietary system IP. After this, that particular record immediately goes idle and expires at our pre-determined interval.

Here's our persistence iRule (modified from the Deployment Guide since we use multiple Virtual Servers):

when ACCESS_ACL_ALLOWED {
    set sessionid [ACCESS::session data get "session.user.sessionid"]
    switch -glob -- [string tolower [HTTP::path]] {
        "/microsoft-server-activesync*" -
        "/owa*" -
        "/ews*" -
        "/ecp*" -
        "/oab*" -
        "/rpc/rpcproxy.dll*" {
            persist uie $sessionid 1800
            return
        }
        "/autodiscover*" {
            persist none
            return
        }
    }
}

when HTTP_RESPONSE {
    if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} {
        ONECONNECT::reuse disable
        ONECONNECT::detach disable
        NTLM::disable
    }
    if {[HTTP::header exists "Transfer-Encoding"]} {
        HTTP::payload rechunk
    }
}

Any ideas?

-Cory

Well, this is a good one! Apparently, the pool statements in this Persistence iRule are meant to cover more than just circumstances where a single Virtual Server is used.

After changing to the shortened iRule above, we get the aforementioned errors in the APM log along with a single persistence record created WITHOUT A Pool to member IP 127.20.2.254:10001. This record goes idle immediately and expires at the inactivity timeout count.

When I restored the Persistence iRule back to the following (inclusive of pool statements), we no longer saw this issue:

when ACCESS_ACL_ALLOWED {
    set sessionid [ACCESS::session data get "session.user.sessionid"]
    switch -glob -- [string tolower [HTTP::path]] {
        "/microsoft-server-activesync*" {
            pool APM_EXCHANGE2010_as_pool2
            persist uie $sessionid 1800
            return
        }
        "/owa*" {
            pool APM_EXCHANGE2010_owa_pool2
            persist uie $sessionid 1800
            return
        }
        "/ews*" {
            pool APM_EXCHANGE2010_oa_pool2
            persist uie $sessionid 1800
            return
        }
        "/ecp*" {
            pool APM_EXCHANGE2010_owa_pool2
            persist uie $sessionid 1800
            return
        }
        "/oab*" {
            pool APM_EXCHANGE2010_oa_pool2
            persist uie $sessionid 1800
            return
        }
        "/rpc/rpcproxy.dll*" {
            pool APM_EXCHANGE2010_oa_pool2
            persist uie $sessionid 1800
            return
        }
        "/autodiscover*" {
            pool APM_EXCHANGE2010_ad_pool2
            persist none
            return
        }
        default {
             This final section takes all traffic that has not otherwise
             been accounted for and sends it to the pool for Outlook Web
             App
            pool APM_EXCHANGE2010_owa_pool2
            persist uie $sessionid 1800
        }
    }
}

when HTTP_RESPONSE {
    if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} {
        ONECONNECT::reuse disable
        ONECONNECT::detach disable
        NTLM::disable
    }
    if {[HTTP::header exists "Transfer-Encoding"]} {
        HTTP::payload rechunk
    }
}
definition-checksum f41bb1953d96f40c57b91ae927bcaa4f

Does anyone know what would be happening with this strange IP? I'm just curious at this point as I seem to have corrected my own foul-up. 🙂

-Cory