Why do I have to uncheck ""Advanced Network Functionality"? - a detailed scenario
I have had a couple of HTC phones now, and I have always had to uncheck "Advanced Network Functionality" to solve the problem I describe below, but I am curious as to the actual cause. Specifically I am unclear as to if there is another way to fix my RNDIS communications issue w/o unchecking this feature.
The initial sync set up method (USB versus OTA) doesn't matter - If I hard reset the phone (leaving this feature checked), then connect the phone to my PC (doesn't matter if it's XP w/activesync or 7 with MDC) the sync to Exchange works fine and the problem is reproduceable. If I hard reset the phone (leaving this feature checked) and set up the connection OTA to Exchange, the sync works fine as well and the problem is reproduceable. So it doesn't seem to matter way I created the sync originally, the problem occurs.
The problem comes from when I sync to the computer via USB succesfully, with the check box checked, then disconnect USB chord the phone and try to use it OTA. At that point I am no longer able to establish OTA communications with Exchange. If I soft reset the device I am fine as communications resume normally. However once I connect the phone to the computer through USB, and then disconnect it, OTA Exchange synchronization stops again.
As you can imagine rebooting your phone just because you unplugged it from from your computer and you want Exchange OTA is not desireable. The only way to resolve this is to uncheck the "Advanced Network Functionality" feature, but this would get to be hard to manage for a large number of users.After doing a bunch of research, this appears (but I am not sure) to be because I use the same server name as a connection point internally and externally with different IPs. For example lets say the server name defined as the connection point for Exchange is mobile.company.com, interinally that name resolves to a 192.168.X.X address, and externally the same name resolves to a public IP.
I understand this changes the communcation method from RNDIS back to PPP:
http://www.pocketpcfaq.com/faqs/activesync/usb-advanced-functionality.htm
Why would switching between an internal and external IP cause an issue with RNDIS, but not PPP? Shouldn't DNS refresh after the TTL expiration period of the host name? Internally the record is by default a 1 hour expiration, but I have seen the phone unable to communicate to Exchange for over 6 hours w/o a connect and require a reboot.
Is there another way to hanlde this besides unchecking the afore mentioned feature? I cannot connect to the Public IP internally due to the nature of the routing of the network, so I am unable to test if just a single IP address for the DNS host name would resolve anything.
I would imagine a lot of small businesses are set up the same way I am where they can't connect to their external IP internally, and so they rely on an internal IP and external IP for the same DNS name.
I am looking for an alternative to unchecking "Advanced Network Functionality" in an internal/external shared namespace because I am sure I will run into it again with other users, and I would like to avoid turning it off if it is on by default.
Thanks!
Answers
- Hi,
You've asked some interesting questions so here's my reply.
Basically the PPP implementation is very different than the RNDIS implementation in the following ways:
1. They use different IPs on the PC and the device. So if your firewall on your PC does not support the new IPs of RNDIS it will fail.
2. The PPP stack is a private stack that is not the same as the PPP stack on the PC that ships with Windows. This can allow it to function when RNDIS fails.
3. They use different drivers.
The issue of the IP address of Exchange highlights another issue within Windows Mobile. Windows Mobile caches the DNS lookup longer than the TTL requirements. Also, it does NOT flush the cache when a new connection is made. So I highly recommend to enterprise customers to ensure that the external IP address be accessible from within their network to ensure that users can continue to access their e-mail from their desktop.
BTW, with the latest devices and WMDC or ActiveSync 4.5 you can enable an external internet connection on the device. This should allow your e-mail to continue to work with Exchange without changing your environment. However it may expose your PC and network to data coming via the internet connection on your Windows Mobile device. Some companies do not allow you to connect to the internet while synchronizing due to this risk.
Chris De Herrera
http://www.pocketpcfaq.com
http://www.pocketpctalk.com- Marked As Answer byChris De HerreraMVP, ModeratorWednesday, November 04, 2009 4:50 PM
All Replies
- Anyone out there have a clue? I am still searching as to why I have to turn this functionality off to keep activesync working.
- I'm going to forward your thread to one of the mods that is very knowledgeable in this area HotFix. Give it a day or so to see if he offers you some insight.
Jack Cook
http://www.experiencemobility.net
http://www.mobilitysite.com - Hi,
You've asked some interesting questions so here's my reply.
Basically the PPP implementation is very different than the RNDIS implementation in the following ways:
1. They use different IPs on the PC and the device. So if your firewall on your PC does not support the new IPs of RNDIS it will fail.
2. The PPP stack is a private stack that is not the same as the PPP stack on the PC that ships with Windows. This can allow it to function when RNDIS fails.
3. They use different drivers.
The issue of the IP address of Exchange highlights another issue within Windows Mobile. Windows Mobile caches the DNS lookup longer than the TTL requirements. Also, it does NOT flush the cache when a new connection is made. So I highly recommend to enterprise customers to ensure that the external IP address be accessible from within their network to ensure that users can continue to access their e-mail from their desktop.
BTW, with the latest devices and WMDC or ActiveSync 4.5 you can enable an external internet connection on the device. This should allow your e-mail to continue to work with Exchange without changing your environment. However it may expose your PC and network to data coming via the internet connection on your Windows Mobile device. Some companies do not allow you to connect to the internet while synchronizing due to this risk.
Chris De Herrera
http://www.pocketpcfaq.com
http://www.pocketpctalk.com- Marked As Answer byChris De HerreraMVP, ModeratorWednesday, November 04, 2009 4:50 PM
- Thanks for the fast reply Chris!
Jack Cook
http://www.experiencemobility.net
http://www.mobilitysite.com - Based upon your excellent breakdown, it sounds like the issue I am seeing is the device not wanting to switch back to an external IP after it uses ActiveSync on the internal computer. It's interesting that if Windows Mobile is using the external IP and then is connected to ActiveSync on the PC, that it has no problem switching from the external IP to the internal IP. A little change to the code such as having the device refresh the DNS record after disconnecting from ActiveSync should do the trick.
I think we will see more and more businesses running into this as they start to migrate away from Blackberry devices (which don't suffer this issue) as I know several companies that have different internal and external IPs for the same CAS connection point name, with no access to their own external IPs for their internal staff (it does seem a little silly to me to require them to loop out of their network to only loop back in because of a DNS refresh issue). I could also see this being an issue during a DR event where an entire datacenter is failed over to another location and subsequently the external IP of the CAS connection point changes causing all ActiveSync users having to reboot their devices in order to get them to refresh the DNS record of the ActiveSync connection point.
I am surprised more people haven't complained already, but then again turning off RNDIS does "solve" the issue even if it isn't the best solution.
As you pointed out, I think enabling and external connection through the phone during a PC based ActiveSync connection would be a security violation as it would bypass any inbound/outbound IP traffic filtering controls the company has in place.
So is it possible to file a DCR (assuming you work for Microsoft or have the connections with the right people) with the Windows Mobile product group to allow Windows to more intelligently cache the IP of the CAS connection point? Otherwise customers run the risk of their clients loosing connectivity due to inefficient DNS caching using the default RNDIS method.
At this point I personally would settle for a way to manually refresh the record on the phone short of rebooting, but that isn't a long term solution to roll out to users. - Hi,
Thank you for your reply.
I do not work for Microsoft so I am unable to file a DCR regarding the name resolution issue. I know that Microsoft is aware of the issue based on my conversations with the product teams from Windows Mobile. I believe that this is not as common of an issue because most Exchange ActiveSync users do not sync their PC with a desktop PC except for the occasional application installation.
The only other way I know to flush the cache is to disable all wireless connections and then re-enable it. So this would provide you with a quick way to fix it.
Chris De Herrera
http://www.pocketpcfaq.com
http://www.pocketpctalk.com - Coming from a very heavy Blackberry background (I was using BB's before anyone knew what they were and before there was really a BES), most users from my experience "cradle" their device when they get into the office to charge it and to stop it from alerting them to all the new email. Granted this has decreased over time since the BBs became cell phones, but the old school crowd seems to still have this nature. So as people start to finally transition over from BB to ActiveSync, I see this happening more and more as even today plugging the device into my computer when I am at it is second nature for me.
Either way thanks again for your detailed response and follow on. At least I know my suspicions were right and I can hopefully try to get my TAM to file a DCR for 6.5.1.
