Many Exchange Server migration scenarios involve making DNS changes that can impact a very large number of customers at once if they go badly.

Similarly, we often need to isolate network elements such as load balancers or DNS round robin configurations when troubleshooting client connectivity issues. Making changes to a load balancer or DNS record for this troubleshooting carries a similar risk to those changes made during migrations.

Instead of making a risky, high impact change to your environment you can instead use a hosts file on one (or a few) test computers to achieve the same outcome. The hosts file on the computer will override any DNS results that would be returned for a server lookup, allowing you to have just those specific client computers pointing to a different location for Exchange services such as Autodiscover, Outlook Anywhere, and so on.

host-files-01

Modifying hosts files is a quick and easy task. It requires elevated privileges, so first I like to start an elevated CMD prompt.

start-menu

The CMD prompt will usually start in the C:WindowsSystem32 folder. Navigate to the driversetc subfolder.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:Windowssystem32>cd driversetc

Then launch Notepad to edit the hosts file.

C:WindowsSystem32driversetc>notepad hosts

Any lines in the hosts file starting with a hash character are comments, and will have no effect on the system. Add your desired entry to the hosts file by typing the IP address, pressing tab, then typing the fully qualified domain name. For example, here I am configuring mail.exchangeserverpro.net to resolve to 10.1.4.30 to go directly to a Client Access server instead of resolving to the VIP of the load balancer via DNS.

host-files-02

Save the file and close Notepad. Next you need to restart the DNS Client service. You can do this from the CMD prompt as follows:

C:WindowsSystem32driversetc>net stop "DNS Client"
The DNS Client service is stopping.
The DNS Client service was stopped successfully.


C:WindowsSystem32driversetc>net start "DNS Client"
The DNS Client service is starting.
The DNS Client service was started successfully.

Restarting the DNS Client service is often enough but a full restart of the PC would be advisable at some stage to thoroughly test the change.

If you’re using hosts file for this type of testing or troubleshooting just remember to keep track of which computers you’ve changed them on so that you can go back and remove the entries later. I have encountered many cases in the field where a hosts file change was forgotten about and that particular computer experienced frequent issues as a result.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Nima

    Hi.Even if I enter a wrong IP address with mail.domain.com and autodiscover.domain.com in hosts file , outlook will open and states that it connected to exchange server successfully.
    Would you please tell why this happens?

    1. Sean

      Try reboot the computer and create a new outlook profile.

  2. edwin

    I’m just in the middle of testing my pre-production exchange 2013 envoironment with this trick, and I’ve got something strange.
    My namespace consist of outlook.domain.lan and autodiscover.domain.lan
    Both are added in the hosts file as:
    10.10.1.100 outlook.domain.lan
    10.10.1.200 autodiscover.domain.lan
    I can ping both, and the right ip comes back.
    If I nslookup autodiscover.domain.lan it comes back with the ip from the production environment.
    Also when outlook tries to configure the profile for a user with a mailbox on 2013 it takes a very long time to complete and after starting outlook it displays an error stating that the exchange server is offline.
    I must be doing something wrong but I just can’t see it anymore, hope you can shed some light.

    1. edwin

      Turned out to be port 444 being blocked on the firewall….

  3. Dan Powell

    Excellent tip, thank you very much.

Leave a Reply