Member Avatar for tan00001
tan00001 0 Newbie Poster

When setting up Outlook Anywhere in Exchange Server 2007, all the steps described in "Exchange Server 2007 End-to-End Scenario" are not enough. You need to run the following command in the Exchange Management Shell:

Get-AutodiscoverVirtualDirectory | set-AutodiscoverVirtualDirectory
-ExternalURL https://your-iis-server.yourdomain.com/Autodiscover/Autodiscover.xml

Here "your-iis-server" is the IIS server name where you have your Exchange "AutoDiscover" Web application hosted.

Besides this extra step, all the steps described in "Exchange Server 2007 End-to-End Scenario" must be followed exactly. You can get to "Exchange Server 2007 End-to-End Scenario" by clicking on the root node in the left pane of the "Exchange Management Console". The "End-to-End Scenario" is on the second tab.

On the client side, as long as your local LAN setup works, you can leave it alone, even if you use domain names that are not publicly accessible since virtual RPC over HTTPS will take care of that automatically. All you need to do is to check the "Connect to Microsoft Exchange using HTTP", and setup "Exchange Proxy Settings". This is located in the email account setup dialog box. Click on "More Settings...", and then go to the "Connection" tab. Outlook Anywhere settings is at the bottom of this tab. Your Exchange server IIS external URL should be entered in the "Exchange Proxy Settings" dialog box as the proxy server URL.

One thing you should do is to keep all your authentication protocol consistent. If you choose to use NTLM, use it at every step. Otherwise use "Basic Authentication" everywhere.

  • 1 Contributor
  • 0 Replies
  • 279 Views

Dani AI

Generated

Good catch by — Exchange 2007 will happily complete the EMC walkthrough yet still fail external Outlook connectivity if Autodiscover’s externally reachable endpoint isn’t explicitly published. Setting the Autodiscover external endpoint on the Client Access side is the right fix, but there are a few adjacent items people commonly miss that cause the same symptoms.

Checklist to verify before declaring success:

  • Certificate: the public certificate used by IIS must include the external names (subject or SAN) that clients use, and the full chain must be trusted by remote clients.
  • DNS / split-brain: external DNS must resolve your Autodiscover name to the CAS; internally either publish the same name in internal DNS or provide SRV fallback if your internal domain differs.
  • Edge device / proxy: TCP/443 must reach the CAS (or your reverse proxy) with SSL handled so the certificate presented matches the external name. If using SSL offload, ensure the proxy re-encrypts with a certificate that matches names Outlook expects.
  • Authentication: pick NTLM or Basic and apply the same scheme across IIS virtual directories and any proxy; mixed auth is the most frequent cause of intermittent 401/403s.

Quick tests and tools to use (from the CAS/EM Shell and client side): run the Exchange web-services/connectivity tests (Test-OutlookWebServices, Test-OutlookConnectivity) and exercise Autodiscover with a clean Outlook profile. Microsoft’s online connectivity tester is useful for an external perspective.

Common failure patterns and remedies: 401/403 = auth mismatch; certificate warnings = wrong name or incomplete chain; 404 on Autodiscover = virtual directory not configured or mispointed. When making changes, document current values, test internally and externally, and restart IIS/CAS services only after validating settings.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.