Clients connecting to recently installed servers, but the clients have delayed/no connection
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.