Multi site Exchange 2010 deployment. Failover and Autodiscover

Question

I have made some significant changes to my Exchange environment that have me a little confused as to how to proceed.
A few months ago I upgraded from SP1 to SP3 UR5 and my previous strategy for DR stopped working.
Just to give a little background:
I have two sites connected with a 100Mb ethernet link that each have a dag member with a hub transport and two CAS servers.  These servers at each site are load balanced with a Kemp Technologies LM-2200 cluster.
Previous to the upgrade we were working in warm standby where a passive copy of the mailbox databases were being held in the second site but not being used until needed.  When needed we would change the load balancer to connect users to the second site
or in the case of a site failure we would change DNS to point to the second site.  After the upgrade things changed and I could no longer do cross site RPC out of the box and when I enabled cross site RPC it still did not work like previous so I figured
this would be a good opportunity to strengthen my setup and try to go for a more automatic failover design were each site gets its own namespace and the CAS servers can redirect users to the correct site based on the current state of the DAG.
This works great aside from the folks who are not connected to the domain to get SCP.  For instance I have activesync devices and OWA users on the outside.  If the primary site goes down before these devices make an attempt to connect they will
not know that the site is down and their mailbox is now active in the secondary site.  The device will just fail to connect.
Is there any way to make autodiscover site resilient?  The only thing I can think of is using round robin DNS for autodiscover but that would likely cause some connection troubles if the site that is randomly resolved happens to be down.
Thoughts on this would be appreciated.
Thank you,
Nick

Answer 1

I realize that DAC mode does nothing but prevent the databases from mounting without open communication between the DAG members.  I was not insinuating that it would help with my DR strategy other than that I know I could run into trouble if I do not
enable it and the DAG members come online but cannot talk to each other.
I realize that the alternate witness does not activate without intervention.  If you read my reply you would see that I am not interested in full DR being automatic.
"I do not expect to have zero intervention when doing a datacenter switchover but I would prefer to have it as automated as possible when there is a simple failure of the primary dag member and the witness is still available.  We have had this happen
a few times when the information store service has failed due to bugs in old code and the second site came online without difficulty."
I realize that everyone says HA should be provided by DAG nodes in the same site but I do not have that luxury right now.  In most of the cases were this would even apply a second DAG member in the same site would do me no good because typically the
issues that have caused failover in the past have been related to the underlying systems of our VM environment (storage, network, blade chassis).  There is no reason that an automatic failover DAG cannot be maintained across a strong Ethernet link between
sites as long as the limitations are well documented and followed.
In the case that I have to run Exchange out of the DR site alone I would bring up the alternate witness server and remove the primary DAG member from service giving the DR site majority and users would connect to Exchange via the DR namespace.
Regardless of all that the original question I had has not been answered.  How does autodiscover get handled in a scenario like this?  If my autodiscover addresses are pointed at a site that is not operational devices will not know where to go
for services.  Is my only option to repoint DNS and wait hours for the record changes to propagate?