Forum Discussion
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_111Historic 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_25555Historic 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_Shimku2Historic F5 AccountSounds 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_25555Historic 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_25555Historic 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_111Historic 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_25555Historic F5 Account
Thanks, Mike. We'll give this a try and report back.
- Evan_25555Historic 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_111Historic F5 AccountI 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_25555Historic 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.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com