devon-lad
asked on
Forcing Outlook Anywhere connection on internal clients
For various routing and security reasons, we've decided it would be best if all internal Outlook 2013 clients access the in-house Exchange 2013 server (at another site) from an external connection (using Outlook Anywhere) instead of going through the site-to-site VPN.
Assume internal hostname is internal.company.com and external hostname is external.company.com
To achieve this, the following steps have been taken:
1. CNAME setup in internal DNS pointing autodiscover to external.company.com
2. Autodiscover SPC in AD sites and services changed to external.company.com
3. Run Set-OutlookProvider expr -certprincipalname:"msstd:
Initial test machines worked fine - but as we started to roll out we saw some odd results.
Machines that had routes to the mail server via the VPN had their Outlook Anywhere proxy set to internal.company.com - and they worked fine.
Machines that didn't have routes to the mail server had their OA proxy set to external.company.com - autodiscover worked fine, but then after that they couldn't authenticate.
Most oddly, a non-domain machine on an external connection that can't even resolve the internal hostname, let alone connect to it, has had its proxy set to internal.company.com - and it works!?
Can someone clarify what might be happening here?
Assume internal hostname is internal.company.com and external hostname is external.company.com
To achieve this, the following steps have been taken:
1. CNAME setup in internal DNS pointing autodiscover to external.company.com
2. Autodiscover SPC in AD sites and services changed to external.company.com
3. Run Set-OutlookProvider expr -certprincipalname:"msstd:
Initial test machines worked fine - but as we started to roll out we saw some odd results.
Machines that had routes to the mail server via the VPN had their Outlook Anywhere proxy set to internal.company.com - and they worked fine.
Machines that didn't have routes to the mail server had their OA proxy set to external.company.com - autodiscover worked fine, but then after that they couldn't authenticate.
Most oddly, a non-domain machine on an external connection that can't even resolve the internal hostname, let alone connect to it, has had its proxy set to internal.company.com - and it works!?
Can someone clarify what might be happening here?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
BTW Simon, did you used to do Windows Mobile development around 15 years ago?
ASKER
Seems like if we avoid autodiscover and manually setup Outlook Anywhere with NTLM authentication we can connect to the mailbox. But anything to do with autodiscover is prompting for passwords.
Outlook Anywhere is set to Negotiate on the server - maybe this should be set specifically to NTLM?
Outlook Anywhere is set to Negotiate on the server - maybe this should be set specifically to NTLM?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Found solution myself but useful comments from Simon
ASKER
Outlook Anywhere settings show internal.company.com for Internal URL and external.company.com for the External URL.
If I do an nslookup on internal.company.com from the external client it reports non-existent domain, so no wildcards in play.
Although proxy settings in Outlook show internal.company.com, if I look at the Outlook connection status it shows external.company.com is being used ??
However, this oddity is not the main issue at the moment - the main issue is that internal clients that don't have direct access via the VPN do not seem to be able to connect.
Are the steps I've taken as listed correct/necessary - or were those unnecessary/incorrect. The machines I was initially testing on did not work until these configs had been applied.