Dwight Ricks had another idea. "Weve seen similar situations arise, but usually when a VPN is involved. You didnt mention in the newsletter if that was the case or not. To resolve it for us, when there is a VPN, we access the advanced button for TCP/IP properties and clear the 'use default gateway on remote network' checkbox. We then add an entry into the hosts file for the exchange server. Finally, we increase the timeout when accessing the exchange server from the default 30 seconds to 120 seconds. Works well for us." Although we should be using a VPN, we weren't on that machine.

John Code also thought of the VPN idea and then dismissed it. "You didnt state if the staffer was establishing a VPN connection first or not. I will assume not. For our users the only way I can get our external users to resolve this way is by putting a host entry with the name of the Exchange server resolving to the external address of your firewall/entry point. This can be easily tested by going to the command prompt and pinging the Exchange server name. Does it resolve? If Not add the host entry name and try again."

John also asked an interesting question. If anyone has an answer to it, we'll forward it on to John: "On a side, I have not really found a straight answer from anyone why when you key in the Exchange server name that you cannot put in a fully qualified domain name instead of the Exchange server name. I would prefer DNS (by using Internal/External resolution) to resolve the Exchange server name instead." Anyone know if this is possible? Send your answers to me at david@ZATZ.com.

A couple of folks thought we might be dealing with a profile issue. Christopher Stewart wrote in, "This sounds to me like a profile issue and/or Outlook registry setting issue to me. I would keep the user's current Outlook profile on that machine and create a new one with a different name, but with only the Exchange server service installed first -- No Address Book, PSTs, etc. If that works fine, start adding any additional services that are in the problem profile. If you get them all added without any issues, then it was simply a corrupt profile. Delete the old one, and good riddance!

"If when you add the Exchange server service to the new profile, it exhibits the same problem, it is probably a registry setting that is corrupt. I would try running Outlook in safe mode (outlook.exe /safe) to see if that helps. Sometimes that will help identify a problem add-in. Of course, going to Tools/Options/Other/Advanced/Add-In Manager is more granular. Do that if the safe mode helps. If all else fails, uninstall Office and run the cleaner program to whack all Office related registry entries. Then make sure you go through the Office directories (program and user) and clean all those out."

Ryan Ornelas had a similar approach: "Often there are times when dealing with remote users when they are unable to connect with the Exchange server. First, we have them recreate their Outlook profile, hoping to re-establish a connection with the Exchange Server. If they are unable to resolve a name, then I will have them browse to the Exchange server from the RUN command. If they have changed their password, then it will ask them for their new password. This has been the case many times, once they authenticate the password, they can usually log on. If that doesn't work, then we have to move their mailbox to a different server. Seems strange that these steps are needed, but it has been the quickest and easiest way to resolve some of the remote issues we have in our environment."