I hope someone can help me with this...Ive implemented Exchange 2007 in a new domain for a customer who already has Exchange 2003 running in their primary domain. The newdomain is firewalled off from the primary domain but we have ports open between the two domain controllers to allow a trust between the two domains. We are migrating some of the users mail boxes, just mailboxes not user accounts, into the new domain and have set up Outlook Anywhere so that they can access their mailboxes on their usual LAN without us needing to open dynamic ports for RPC or specify static ones. We have opened the HTTPS port from the user LAN to the server LAN. By and large everything seems to work fine, we can create new mailboxes and associate them with accounts in the primary domain and users can access them via Outlook Anywhere ... except that, however I configure the Exchange environment users are always prompted for a password before outlook can connect. They can enter the password for the primary domain and connect OK but the desire here is to have the logon seamless, like it would be normally. Theenvironment is a physical CCR cluster running Windows 2008, two hyper-v HT/CAS boxes running NLB for web protocols. I have disabled IPv6 in the registry on the two HT/CASs. There's no firewalling between the servers in the resource domain, just beween the resource domain and the primary domain. The client machines are running XP and Outlook 2003One slightly unusual thing is that the IP addresses are NAT'ed between the two networks, in one direction, so the IP's that machines in the primary domain resolve for the resource domain are the correct ones, but in the other direction they are translated. This means that although we have DNS forwarding between the two domains, the addresses that are returned in the resource domain are useless, and we need to use a host file to get the correct addresses. I can't see why it would work at all if this was the issue though.Anyone have anyideas? I'm fairly sure I've got autodiscover set up right - everything works perfectly if inside the resource domain & LAN, just not from the primary domain & LAN.

Are the 2 domains in the same forest?To my knowledge NAT on the internal network will make some things break, such as Kerberos and possible NTLMlasse at humandata dot se, http://anewmessagehasarrived.blogspot.com

No they're in different forests. Reading up I see there's a good chance of kerberos failing through NAT but if I configure the outlook client to only use NTLM it still fails. IfI configure OWA to use NTLM auth instead of forms everything works just how you would expect.I've changed so many settings so many times I'm reinstalling the rpc proxy and the CAS role to try and get back to the defaults and start from there, but any extra tips would be great.Kit

Hi, I suggest that you save passwords by using following method on the client: a. Run control userpasswords2b. Under Advanced tab, click Manage Passwordsc. Please add following entry: Log on to: *.domainname (such as *.microsoft.com)Username: domain\usernamePassword: password Then, please check whether we still need to provide password when logging on Outlook. I also suggest you read the following article: Outlook & Exchange via RPC/HTTP(s) / Outlook Anywhere / Outlook via Internet & NTLM password savinghttp://www.css-networks.com/2008/09/outlook-exchange-via-rpchttps-outlook-anywhere-outlook-via-internet-ntlm.html Thanks Allen

I would start with a test account in the resource forest to run with outlook anywhere and NTLM auth. when you get this running you can try with an account in the primary domain/forest.lasse at humandata dot se, http://anewmessagehasarrived.blogspot.com

Hi all, and thanks for the suggestions which got me looking around in the right places. Looking into whether it could be a kerberos issue got me looking closer at where authentication failed - with rpcping I could see that I was successful on all ports for an account in the resource domain but failed on 6004 for an account from the account domain. Setting the eventloglevel for MSExchangeSA\NSPIProxy to high led me to finding out the NAT for one of the domain controllers in the resource domain was wrong, so everytime the mailbox cluster tried to authenticate users from the account domain on that DC authentication would fail.It doesn't seem to quite fit the symptoms we were getting (I'm confused as to how OWA always worked, and why users could enter their password when prompted and authenticate OK) but as soon as we fixed that, the problems went away.Thanks for your help.