Issue
**************
Clients were trying to connect to servers that were recently installed, but currently offline for the process of completing setup, causing the clients to have delayed, or no connection at all.
Cause
*************
The servers were not set with the right URL, and once the servers are installed into a site, autodiscover will query AD to get the URL and other information, even if the servers are offline, the information is in AD and can be returned to users.
Once the users received the Internal URL for the offline servers, they would try to connect to that internal URL, and eventually timeout, then they would connect to the externally listed url, https://mail.test.com
Resolution
**************
We did a couple of things to try and prevent users from getting to the down servers
1. We set the SCP autodiscover record to be mail.test.com on the 4 new servers
a. Set-clientaccessserver –AutoDiscoverServiceInternalUri https://mail.test.com/autodiscover/autodiscover.xml
2. We then went into ADSI edit and modified the internal URL for outlook anywhere on the 4 new servers as well
3. We then restarted the app pool for autodiscover to clear the autodiscover cache
a. This then allowed users to set the connection point to mail.test.com
4. For clients, they may need to do a repair profile to remove the server FQDN from the outlook profile and restart outlook
Next Steps
************
When the 4 new servers are brought back up verify that the outlook anywhere settings are correct from powershell.
Get-outlookanywhere <NEW SERVER NAMES> | fl
Check internal URL and make sure it is mail.test.com
May want to change the Internal URL to the mobile. For all the servers, removing the internal FQDN
Also change the AutoDiscoverServiceInternalUri for the client access servers to mail.test.com, so users do not try to use an individual server name when they discover an SCP record.
Ex-Shell 