Forum Discussion

Evan_25555's avatar
Evan_25555
Historic F5 Account
Oct 21, 2014

Exchange 2010 deployment: Mobile devices are being reprovisioned

We have both production and development Exchange 2010 deployments. Our internal IT group have configured their mobile devices to point at the development deployment which is using the latest iApp template available for 11.4.1. We've discovered the our phones are getting automatically "reprovisioned" to point at the production deployment.

 

Has anyone else experienced this? Any thoughts at what might be at work here?

 

10 Replies

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account

    Hi Evan, if you bypass BIG-IP and point directly at the CAS, does the problem go away? Is the Autodiscover response pointing users to the dev environment for ActiveSync?

     

    thanks

     

  • Evan_25555's avatar
    Evan_25555
    Historic F5 Account

    Thanks, Mike - we'll give that a try. Our exchange guy swears that the security team made him turn off autodiscover so we don't believe that is in play.

     

    • Michael_Shimku2's avatar
      Michael_Shimku2
      Historic F5 Account
      Sounds good. If it is the BIG-IP, you can use tcpdump or an iRule to inspect the ActiveSync request and response for clues as to why it would provision the device again for the other environment.
  • Evan_25555's avatar
    Evan_25555
    Historic F5 Account

    Thanks, Mike. We're running rotating tcpdumps so we can inspect the ActiveSync requests when the re-provisioning occurs. Hope to have an update soon.

     

  • Evan_25555's avatar
    Evan_25555
    Historic F5 Account

    I'm finding that resulting ssldump is of limited value in part due to the absence of time stamps. Do you have any suggestions regarding how we might employ an iRule to inspect the ActiveSync requests?

     

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account

    You could create a rule similar to this and attach it using the iRules option in the iApp:

    when HTTP_REQUEST {
        set is_activesync 0
        switch -glob -- [string tolower [HTTP::path]] {
            "/microsoft-server-activesync*" {
                set is_activesync 1
                log local0. "Request:[HTTP::host][HTTP::uri]:[HTTP::header names]"
                foreach cookie [HTTP::cookie names] {
                    log local0. "Cookie name: $cookie, Cookie value: [HTTP::cookie value $cookie]"
               }
                foreach aHeader [HTTP::header names] {
                    log local0. "$aHeader: [HTTP::header value $aHeader]"
               }
            }
        }
    }
    when HTTP_RESPONSE {
        if { $is_activesync == 1 }  {
            log local0. "Response: [HTTP::status]:[HTTP::header names]"
            foreach cookie [HTTP::cookie names] {
              log local0. "Cookie name: $cookie, Cookie value: [HTTP::cookie value $cookie]"
           }
            foreach aHeader [HTTP::header names] {
              log local0. "$aHeader: [HTTP::header value $aHeader]"
           }
        }
        unset is_activesync
    }
    
  • Evan_25555's avatar
    Evan_25555
    Historic F5 Account

    Thanks again, Mike. With the help of your iRule, we captured this response that we believe is reprovisioning our phones.

     

    Oct 22 20:36:50 slot1/XXX-ADCDMZ-01 info tmm1[12016]: Rule /server_team/log_ActiveSync_requests : X-MS-Location: https://smtp.example.com/Microsoft-Server-ActiveSync

     

    • mikeshimkus_111's avatar
      mikeshimkus_111
      Historic F5 Account
      I found this information about that header: http://msdn.microsoft.com/en-us/library/gg651019(v=exchg.80).aspx This is coming from the CAS. Assuming the dev environment CAS is what the test users are hitting first, is that dev Exchange deployment misconfigured? You could always use the iRule to rewrite the X-MS-Location header value in the response, but that's a bit of a hack.
  • Evan_25555's avatar
    Evan_25555
    Historic F5 Account

    Thanks again, Mike. We actually ended up changing the X-MS-Location related configuration on one of the servers to point at our test environment and removed the other two servers from the pool.

     

    I should note that the problem we experienced is specific to environments that have multiple Exchange deployments.