EDIT 8/22/2008: Corrected a typo in a "DisabledComponents" registry key name. It's been a while since I've been thinking of writing a blog post about various aspects of Outlook Anywhere that people have been asking questions about. Somehow, I keep getting myself caught up in one thing or another, and have consequently delayed writing this blog post by almost 4 months. Ugh. Better late than never I figure. Given how long this blog post is overdue, I plan to cover a lot of topics, from frequently asked questions to common misconceptions to problems with Outlook Anywhere to suggested solutions for different problems. How does Outlook Anywhere work? I won't cover details on the cmdlets that enable and change settings for Outlook Anywhere. There is already a bunch of documentation on it. Instead, let's do a slightly deeper dive than the cmdlet documentation provides. The values that you provide to Outlook Anywhere settings can be classified into 2 types of properties - client facing and server facing. Examples of client facing properties are ClientAuthenticationMethod, External Host Name. Examples of Server facing properties are IISAuthenticationMethods, SSLOffloading. Client facing properties are picked up by Autodiscover and supplied to Outlook to configure client access to the Outlook Anywhere service. Server facing properties are picked up by a servicelet called RpcHttpConfigurator which runs as part of the Microsoft Exchange Service Host service. This servicelet runs every 15 mins by default, but the interval can be adjusted by changing the value of the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\PeriodicPollingMinutes regkey. Note that setting this value to 0 turns off the RpcHttpConfigurator. When the RpcHttpConfigurator runs, it picks up the IISAuthenticationMethods and SSLOffloading values from the AD and stamps it on the \rpc vdir settings in the IIS metabase - overwriting any previously set value. This means that if you manually change the settings on this vdir, you should expect to be run over pretty shortly by the RpcHttpConfigurator (unless you have set the reg key to 0). Ok, so that's just part of what the servicelet does. Outlook Anywhere depends on the RPC/HTTP Windows component to do the marshalling and unmarshalling of the RPC packets from the client to the CAS server. A client side RPC component is responsible for marshalling every RPC packet into an HTTP tunnel and sending it over to the \rpc vdir on the CAS server. RPCProxy is an ISAPI extension that unmarshals the RPC packet, retrieves the RPC endpoint that the client wants to talk to and forwards the packet to the endpoint. But imagine if you were able to connect to any server in the organization if you were able to auth against an IIS box running RPCProxy. By the weakest link theory, all you'd need to do would be hack into a single IIS server and you'd have free access to all servers in the org. Ouch ! To alleviate this problem, RPCProxy only allows connections to be made to servers and ports that are in a trusted list. This list is maintained through the HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy\ValidPorts regkey and contains all the servers/ports that RPCProxy is allowed to talk to. So, the other part of what the RpcHttpConfigurator servicelet does it that is queries the AD for all mailbox servers and stamps them in the ValidPorts regkey allowing access to ports 6001, 6002, 6004 for both FQDN and Netbios access. So, you will typically see something like mbx1:6001-6002;mbx1:6004;mbx1.contoso.com:6001-6002;mbx1.contoso.com:6004 as the value for the key. As new mailbox servers are added to the org, they will be picked up when the servicelet runs and be added to the key. Again, if you manually change this regkey, you should expect to be bulldozed by the servicelet. Note that the ValidPorts key is only used by RPCProxy as a filter to disallow communication with unlisted server ports. It is not used to determine which server to send requests to. For the same reason, the order in which servers are listed in this key does not matter. I just thought I'd clarify this since I was recently told that there was confusion on what this key accomplished. Ok, simple enough, now that all the configuration is done, how does Outlook Anywhere actually establish its connections. The following diagram may help: As you see above, the client specifies the VIP of the Load balancer (or direct CAS FQDN if the CAS is exposed to the Internet) as the HTTP endpoint and the mailbox server as the RPC endpoint. The query string is somewhat like this: http://nlb.contoso.com/rpc/rpcproxy.dll?mbx1.contoso.com:6001 This tells the RPCProxy on CAS1 that the client is trying to connect to server mbx1.contoso.com on port 6001. RPCProxy looks up the ValidPorts key and if mbx1.contoso.com:6001 is listed there, it allows the connection to go through. The blue and red arrows above represent the 2 different connections spawned by the RPC/HTTP client component to represent a single RPC connection. This is done because HTTP connections are half duplex (i.e. they either allow you to send information or receive information, not both at the same time). In the case of RPC, connections need to be long lived and full duplex, so the RPC_IN_DATA connection acts as the sending half duplex connection, while the RPC_OUT_DATA connection acts as the receiving half duplex connection. Since HTTP requires that each connection be given a max length, each of these connections are 1GB "long" and are terminated when this limit is reached. Each of these connections is tagged with a client session id. When the RPC server component receives the RPC_IN_DATA and RPC_OUT_DATA with the same client session id, it knows that for any request received on the RPC_IN_DATA connection, it must reply back on the RPC_OUT_DATA connection. That's magic. Ok, so you already know this, but I'll reiterate - the mailbox server has 3 ports that are used for RPC/HTTP: port 6001 is used for Mail connections, port 6002 is used for directory referral, port 6004 is used for proxying directory connections to AD. The Referral Service running on port 6002 and DSProxy running on port 6004 are part of the same mad.exe process, and the Referral Service just refers clients back to DSProxy to establish their Directory connections. If you Ctrl+Right Click the Outlook icon and click on Connection Status, it will tell you what connections exist (Mail vs. Directory), what server they are going to and what protocol they are using (HTTPS vs. TCP(direct Exchange RPC connection)). I have conveniently omitted any discussion around certificates, since that can take up another few blog posts. As some would say, that is beyond the scope of this article and is left as an exercise to the reader. How do I know Outlook Anywhere is working? Simple... when no one is complaining! Seriously though, it is preferable is to run diagnostics on Outlook Anywhere before subjecting it to thousands of users. The one tool that works pretty well in most cases is rpcping. Yes, it has a lot of parameters and is confusing, but it does provide pretty good diagnostic information and as long as you have the KB open, you can figure out where problems lie. Start by pinging just the RPCProxy by using the -E option. Once that works, move onto testing the mailbox server endpoints by removing the -E and adding -e 6001 instead. Similarly for 6002, 6004. A typical command line would be something like this. Refer to http://support.microsoft.com/kb/831051 for usage details rpcping -t ncacn_http -o RpcProxy=cas1.contoso.com -P "user,domain,password" -H 1 -F 3 -a connect -u 9 -v 3 -s mailbox.contoso.com -I " user,domain,password " -e 6004 How does Outlook Anywhere not work? Unfortunately, there are some cases where Outlook Anywhere does not work without requiring manual tweaks. This is the part I wish I had blogged about earlier. I'm sure there are poor folks out there that have hit these issues and wasted their time figuring out what I had already learned... DSProxy and IPv6 As of E12 SP1, Outlook Anywhere on Windows 2008 requires that IPv6 be manually turned off on the CAS server. This is because the DSProxy component that listens on port 6004 (mad.exe) for directory connections does not listen on the IPv6 stack. If you do a netstat -ano | findstr 6004, you will see only 1 LISTENING entry - the one that corresponds to the IPv4 stack. Contrast this with ports 6001 and 6002 that have 2 entries. (As most of you already know, if you are running your Mailbox role on the same machine as a DC, lsass.exe not mad.exe listens on port 6004, so this problem will not surface since lsass.exe listens on both protocol stacks.) How do you turn off IPv6 ? It depends on whether you are running CAS and Mailbox on the same server or different ones. If you're in a multi-server scenario where the RPCProxy is not on the same server as the Mailbox, then you need to do the following:

  1. Unselect IPv6 from the properties of your NIC (on the RPC-over-HTTP Proxy machine); that will force the RPC-over-HTTP Proxy to use IPv4 to talk to Exchange and everything will be fine. In most cases, this step suffices. If it does not, continue with steps 2 and 3.
  2. Under the regkey HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters, add a 32 bit DWORD with the name DisabledComponents and value 0xFF
  3. Reboot the machine
If you're in a single-server scenario where the RPCProxy and Mailbox are on the same machine, then the above does not work since the loopback interface still uses IPv6. In this case, you need to make the following changes in the system32\drivers\etc\hosts file:
  1. Comment out the line ":::1    localhost"
  2. Add the following two lines: <IPv4 address>    <hostname of the computer> <IPv4 address>    <FQDN of the computer>
Thanks to Kevin Reeuwijk and others for finding and reporting the issue and solution. A fix (make DSProxy listen on the IPv6 stack) is on the way and is expected to be available in Exchange 2007 SP1 RU4 in Q3 2008. DSProxy and Split RPC_IN_DATA, RPC_OUT_DATA connections In the diagram above, you will notice that I have used a Source IP Loadbalancing layer. This ensures that the RPC_IN_DATA and RPC_OUT_DATA connections coming from a single Outlook instance are always affinitized to the same CAS server. However, there are some legitimate scenarios where Source IP affinity is not viable for customers. A typical example is when a large number of end users are behind NAT devices causing all connections to end up with the same IP and hence the same CAS server... yay load balancing! Outlook Anywhere does not support cookies, so cookie based Load balancing cannot be used either. The only way of spreading load across the server farm is to use with no affinity or SSL-ID based affinity. However, this has the problem that the RPC_IN_DATA and RPC_OUT_DATA connections could (and most likely would) end up on different CAS servers as shown in the diagram below: If you've been reading closely, you'll remember my earlier mention that the RPC server component is well aware of client session IDs and can reply on RPC_OUT_DATA for any requests on RPC_IN_DATA. And if that's the case, we should still be fine since Outlook always specifies the mailbox server as it's RPC endpoint. Well, almost. We are fine for ports 6001 and 6002 which are real RPC end points. The issue is with port 6004 where DSProxy pretends to be an RPC endpoint, but is just a proxy as the name implies. DSProxy only proxies client connections through to the DC. In the example above, RPC_IN_DATA is proxied to DC1 while RPC_OUT_DATA is proxied to DC2. The DCs are the real RPC endpoints. However, now that the 2 connections have been split, neither of the DCs is aware of the other connection and requests sent on RPC_IN_DATA are lost in oblivion. We call this split connectivity and it is a problem surfaced by SSL-ID or no affinity load balancing. While I would recommend not using these configurations if avoidable, it is clear as described earlier that these may be the only alternatives. Think hard if this is the case since the workaround that I am describing below will be tedious to maintain. The goal of these steps is to eliminate the possibility of split connectivity by (1) having clients bypass DSProxy wherever possible and (2) constrain DSProxy to talking to a single DC for any requests to DSProxy. First off, you need to avoid using DSProxy wherever possible. Normally, the Referral Service running on port 6002 refers clients to DSProxy on port 6004. By setting the following regkey, you instruct Referral Service to not send clients to DSProxy, but instead give them a referral to a DC for directory connections. So, instead of client connections going from Client to RPCProxy to DSProxy to DC, the path would be from Client to RPCProxy to DC. Note that the client is not directly connecting to the DC, so it is not required to publish the DCs to the internet or open any new firewall ports. See KB http://support.microsoft.com/kb/872897 for details:

On the Mailbox servers: a DWORD  entry needs to be created on each Mailbox server named "Do Not Refer HTTP to DSProxy" at HKLM\System\CCS\Services\MSExchangeSA\Parameters\ and the value set to 1
Next, as indicated earlier, the RPCProxy will block access to the DC servers unless there servers are included in the ValidPorts regkey. So, set the following on the Client Access Servers
  1. The ValidPorts setting at HKLM\Software\Microsoft\RPC\RPCProxy needs setting so that the entries referring to 6004 point to DC servers in addition to the mailbox server.
  2. The PeriodicPollingMinutes key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\ needs setting to zero to prevent RpcHttpConfigurator from updating the Valid Ports key automatically.
Finally, you need to make sure that the DCs are listening on port 6004:
On the Global Catalog servers: a REG_MULTI_SZ  entry needs to be created on each GC named NSPI interface protocol sequences at HKLM\System\CCS\Services\NTDS\Parameters\ and the value set to ncacn_http:6004
These fixes will make sure that all directory connections bypass DSProxy and terminate at the DCs, thereby allowing the DC RPC server side component to receive both the RPC_IN_DATA and RPC_OUT_DATA connections. There is 1 last thing to deal with in this SSL-ID load balanced configuration. Outlook profile creation hard codes a call to DSProxy on 6004. Which means that we can get split connectivity during profile creation. To deal with this minimal volume of traffic, there is 1 final regkey that should be set on the mailbox servers:
On the Mailbox Servers - set the HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the DC that profile creation should use.
By using only 1 DC for profile creation, all DSProxy calls will be proxied into that single DC, once again avoiding split connectivity. That's it folks! Of course, subsequent releases will provide cleaner solutions for such topologies, but for now, rest assured that having gone through the above steps multiple times, I feel your pain. That's pretty much it. I hope that adds some clarity to how Outlook Anywhere works and hasn't succeeded in confusing everyone even more. Until the next post - Hasta Luego! - Sid
Not applicable
I got Outlook Anywhere working fine on Windows Server 2008 without any special modifications. This server is CAS, HUB & MBX, as well as Active Directory Domain Controller (+Global Catalog). Initially Outlook kept prompting (endlessly) for credentials when using NTLM authentication. (got countless complaints about this from my users) However, it seems to have been fixed now. Not sure what did the trick.

I still have endless prompting on the /OAB virtual directory though. Trying to navigate to /OAB/[guid]/oab.xml works initially, but after some time (settings being applied periodically by some Exchange service?) it fails (HTTP 401).
IIS7 Failed Request Tracing is not helping, NTFS permissions seem correct. After making some modification to IIS7, it seems to work fine again, for a few moments.
To bypass this issue, I've resorted to using Public Folders to distribute the OAB. I'd still like to be able to fix the /OAB issue though.
Not applicable
Thanks Bro. Thanks Indeed.
Not applicable
Hi LookingForSolutions,
Regarding Outlook Anywhere working fine on Windows Server 2008, the reason you did not hit the IPv6 issue is because when Active Directory runs on the same server as the mailbox role, it is the lsass.exe process that listens on port 6004 since directory requests do not need to go off box. lsass.exe listens on port IPv6 and IPv4 stacks. It's only when DC and mailbox server are seperate machines that the IPv6 problem strikes.

About the continuous prompting with NTLM, I have heard that from a few different sources, but haven't received a repro for it yet. If anyone has a consistent repro, please post it so we can look into the problem.
Not applicable
Link to the original blog post that revealed and walked through fixing this problem 3 months ago: http://blog.aaronmarks.com/?p=65
Not applicable
aaronmarks... well it is true that your blog post covers one of things in this blog post... but barely the whole thing! Also - there was a post that came few months before yours that covered that problem too:


So I am not sure what is that you are trying to show?

Sid - awesome post - thank you!
Not applicable
Mike, I'm not trying to show anything other than that many other consultants and I contacted Microsoft PSS many months ago and received no support on this issue in the first weeks that Windows Server 2008 was released.  There is also still no official KB article that covers this bug and thus there are still many consultants who are wasting unnecessary days of their lives trying to figure out how to fix this problem on their own.

To conclude, I'm mostly upset that there isn't a true Microsoft KB admitting to this bug.  After all, Exchange 2007 SP1 on Windows Server 2008 RTM is a supported configuration and yet one of the biggest components does not work in a standard install without some very hidden tweaking.

Side note to Mike, that other article doesn't have an update saying that the problem still exists in the Server 2008 RTM version.
Not applicable
sidm@microsoft.com, I just noticed something odd.

After navigating to /OAB/[guid]/oab.xml (OAB web distribution DISABLED, but /OAB virtual directory still present in IIS and Exchange configuration), and receiving the endless password prompt, Outlook starts prompting for credentials again (when Outlook Anywhere is configured). The credentials prompts disappear after restarting IIS7 ...
Could the OA credential prompting issue be related to the /OAB credential prompting issue?
Not applicable
aaronmarks, product documentation content on this issue is scheduled to be published to TechNet on July 2 (which is when our next content refresh occurs).  It will be listed under http://technet.microsoft.com/en-us/library/cc411322(EXCHG.80).aspx when it goes live.  Hope this helps.
Not applicable
Was it me or did this read like an entry from "The Hitchikers Guide to the Galaxy" ? Otherwise, very good post.
Not applicable
This was some great stuff - thanks!
Not applicable
Very good post indeed, chapeau!

I know some of the Customer's context to which this scenario and the solution apply and find it's useful to say that it works well in an Internet-centric Outlook Anywhere infrastructure, in which all Exchange infrastructure is located in central datacenter(s). The clients in this case connect to EWS from branch offices directly through the Internet, not a company WAN. In a private company WAN with for example MPLS and no internal NAT configurations, the failing load- balancing or resulting RPC connection limits would hardly ever occur (unless the server sizing and scaling is really fubar)

Also, in my opninion, think twice before hard configuring Outlook Anywhere, in the superb service-hacking approach described here, if you are dealing with a large distributed Exchange Org, where DC and Exchange server changes take place frequently.

So with providing solutions i feel it's important to describe the scenarios they apply to a little better, because it better shapes perception.
Not applicable
I have been experiencing the continuous prompting issues
for a week or so running a single 2008 server (all exch
roles and dc). I thought I had fixed it by using using
the shell instead of the GUI to configure outlook
anywhere. That may have taken care of it in one place
but I'm still getting the occasional prompt - I'm thinking
that may be autodiscover issue here:
I just ran that procedure so we'll see how that goes.
Not applicable
Well that didn't do the trick - the problem continues to happen. Outlook Anywhere users experience login prompts that keep them disconnected and sometimes the TCP connected users will get prompted for /OAB - it's driving me batty!
Not applicable
Still having the problems - it's seems to actually be two different issues with similar symptoms:
1. Outlook Anywhere users are prompted for credentials to the Outlook anywhere hostname (listed in the authentication realm). If they do not/cannot enter credentials, then they are disconnected from the server and do not receive mail.
2. Both Outlook Anywhere and TCP connected users are prompted for credentials to /OAB. If they don't/cannot enter credentials, they continue to receive mail.

Restarting IIS always fixes the problem. On the clients, I last night tried right-clicking the Outlook icon, select Connection Status, and then use the Reconnect button, which appears to have temporarily resolved the issue. Other interesting observations, a user with two open Outlook Anywhere sessions on different computers at the same time may experience the issue on one computer but not the other (although both computers do experience the issue intermittently - just not necessarily at the same time). For this reason, I think the issue relates to the IIS session.
Not applicable
I currently have a case open with MS on similar issues reported here. Everything was working fine for a month (Exchange SP1 on Win2008, with necessary hosts tweak) then one day users started getting prompted for credentials right-and-left.

MS is completely stumped, but I have narrowed it down to this specific trigger which is 100% reproducible: *IF* I have OA configured to use NTLM authentication (which was working fine for a month after initial installation) *AND* an Outlook 2007 client attempts to connect to Exchange via OA, *then* NTLM authentication in IIS *instantly* breaks for the OAB (causing random extra login prompts for all Outlook users), and if I leave things go eventually other services like autodiscover also lose their NTLM authentication and start throwing 401s. Restarting IIS instantly fixes the problem until another client attempts to use OA.

Now, the really bizarre part is that this occurs EVEN IF OA IS DISABLED. If OA is disabled *but* it "was" configured to use NTLM authentication, a client even *attempting* to use OA will cause the breakage I mention above. It seems that the handshake the client does to even TRY an OA connection, when NTLM is the configured authentication method, is what breaks things here.

My fix? I simply configured OA to use Basic authentication. Been running rock solid that way for two weeks now. Users get ONE prompt for credentials when they use OA (which is fine by me) and after that they are fine on OA. Internal users connect via TCP, don't get any login prompts, and haven't seen an extra login prompt in weeks.

Now if I could only figure out why OA takes SO LONG to time out trying TCP and falling back to HTTP!! I mean, it should be able to determine Exchange isn't there (via normal RPC over TCP) within a second or so and fall back to HTTP, right? On my system (regardless of the authentication method OA is configured to use) it takes upward of a minute to connect to Exchange :-(

Yeah, I know I could use "on fast networks connect using HTTP first, then connect using TCP/IP", but that defeats the purpose... I only want HTTP used when users aren't on the LAN.
Not applicable
Well I gave up on NTLM and went with basic authentication instead - that did the trick. Fixed both the Outlook Anywhere prompts and the /OAB prompts. My users can't cache their credentials anymore but that's a lot better than having to type them 25 times in a session - hoping that it will work this one time...
Not applicable
Most of my Exchange 2007 Outlook Anywhere implementations have just been configured for basic authentication since the client comptuers using it wouldn't be part of a domain.  Now I have a customer that only uses domain computers for OA, and doesn't want to have a password prompt when using OA on a system that already has a cached logon.  But so far, I can't seem to make it work, no matter what, the user is prompted with a logon box as if it were using basic authentication.
Not applicable
Pufferdude, that's a pretty good description of the environment that repros the issue. We'll try and repro it in-house, hopefully it is as straight forward as it sounds. Once that's in place, I'll provide an update on what we find.
To confirm, you've tried the same with OLK2003 and re-prompting does not occur. It's just OLK2007 ?
Feel free to email me at sidm@microsoft.com with details.
Not applicable

Sorry, I have no idea if the issue occurs with Outlook 2003 clients. We didn't implement the RPC over HTTP when we had an Exchange 2003 server with 2003 clients... we added the Exchange 2007 box, migrated all user accounts to it, then upgraded all clients to Office 2007 *before* even telling them OA was available ;) So, it was only after OLK2007 users started using OA that I discovered the problem.

The weird part is that even though it is NOW 100% reproducible in my environment, it OA *was* working perfectly with NTLM authentication for a couple of weeks before the problem started. Some Windows 2008 updates did come down around the time the problem started, so maybe that was the trigger...
Not applicable
You prompt issue may be related to the certificate mutual authentication requirement for Outlook .

Do your users have this checked in their Exchange proxy settings?

Without this checked, Outlook will prompt even with NTLM enabled
Not applicable
Joseph Durnal: "Most of my Exchange 2007 Outlook Anywhere implementations have just been configured for basic authentication since the client comptuers using it wouldn't be part of a domain."

When working with a non-domain system, OA with NTLM can work fine, as long as the local username and password match the corresponding domain user's credentials.
The password prompting does not appear to be related to the client being a domain member or not. When the prompting starts, all systems have it.

@Guillaume: "Do your users have this checked in their Exchange proxy settings?
Without this checked, Outlook will prompt even with NTLM enabled"

When we got the prompting (after migration to WS2008), we had mutual authentication checked, as before.
As far as I can tell, the problem is related to IIS (/OAB and/or /RPC virtual directories), see my earlier posts. This is 100% reproducable in my environment. Before, with Windows Server 2003, it was working perfectly.

The OA prompting is a really serious issue.
Microsoft should nail this bug as soon as possible.
Not applicable
Hey Folks,
As promised, here's an update on the reprompting issue that many of you have encountered.
The gist of the issue is that IIS7 uses kernel mode windows authentication by default. Turning this off will fix reprompting. I will post a detailed update once I dig through some more and talk to the IIS PD, but for now I wanted to provide this update so you can give it a shot and let me know if (no, "that") it works for you

Here's the command that needs to be run on the CAS boxes ->
%Windows%inetsrvappcmd.exe set config /section:system.webServ
er/security/authentication/windowsAuthentication /useKernelMode:false

Not applicable
sidm, thanks for the update.

More information on the reasons behind the kernel-mode Windows authentication issue would be appreciated: did IIS6 (and lower) support/use kernel-mode WA? what are the consequences of disabling kernel-mode WA (switching to user-mode WA?), etc...
Not applicable
I have a strange problem with outlook anywhere. My outlook anywhere works but when i try to setup outlook anywhere and use netbios name for exchange server instead of FQDN, i could never get it to work. It prompts for password and then says the name could not be matched in address list.

If i remember correctly, i was able to use netbios name for outlook anywhere in exchange 2003. Has this been changed in exchange 2007??

Not applicable
Vinod, since OA is to be used (mainly) from outside the office, you must use a FQDN which is registered in public DNS (unless you want to manually edit the hosts files on all clients). The URL you provide for OA will be supplied to Outlook 2007 clients by the Autodiscovery Service. If it points to a NETBIOS host name, it cannot work (unless you edited the hosts file).
Not applicable
 I'm using the FQDN for the rpc proxy address, eg: webmail.domain.com which is registered in public DNS. I'm talking about using Netbios name for Mialbox server which is working using server.domain.local which is not public dns. This one still works using netbios name in my all other exchange 2003 servers. I'm unable to use them only in exchange 2007 servers. BTW I havent configure my autodiscover and at this time i'm not using it yet..

Not applicable
OH MY GOD THANK YOU THANK YOU THANK YOU! we are running Windows Server 2008, with all the exchange roles on one box but we have 2 separate AD servers. like your diagram. The IPv6 fix with the hosts file did it.

We previously had to have everyone VPN in to configure their email the first time which was a PitA, but now it works flawless without VPN. It's a shame though that I had to have such a headache over it, you would think you guys could push out such a relatively simple fix faster than this.

Thanks so much!
Not applicable
i have outlook anywhere set up and my outlook client point to mail.mydomain.com
i was wondering if i could just set it up to be "mail".  is that allowed?supported?

thanks for the great article.
Not applicable
just to clarify,
we have Outlook Anywhere only running when you access through our VPN, so this is not an external address per-say, but all internal.
would that work?

Not applicable
Avi, that would work if you're VPNed into the network, but that defeats the purpose of Outlook Anywhere. You should change the configuration to mail.mydomain.com and not VPN into the network.
Not applicable

Technically speaking you could add "mail" as a subject alternative name to the Exchange cert on the CAS box and edit the host file on every computer you want configured for Outlook Anywhere to point to the now unchangeable IP address of your internet-facing

ISA or CAS server. Then setup Exchange Proxy Settings with "https://mail" as the url. However, why do that if you could use DNS and spent the rest of your time in a less repetative manner :p

Not applicable
After some time testing access to the OAB folder with IE, I was able to fix it by adding users read only rights to the OAB folder. Checking the existing permissions it looks like it should have been working before the change.
Not applicable
I have very annoying logon request after run Outlook 2007 into Exchange 2007 SP1 on Windows 2008 when running Outlook Anywhere. This logon prompts me to login into mailbox server (why MBOX, not CAS?!). I have multi-role: CCR mailbox cluster and CASHUB with NLB. I'm using NTLM auth for OA.

The strange thing is when I configured succesfuly Outlook with normal MAPI connection, then changed to OUtlook Anywhere and forced to use it - then everything works fine and Outlook work in RPC over HTTPS...but after reboot PC the logon prompt starts again.

Outlook Anywhere doesn't work correctly when I'm trying configure new profile with Autodiscover. It takes a very lont time (but succesfully) and after that it prompts me for logon into MBOX server.
Not applicable
I am having the hardest time resolving Outlook Anywhere in a single-server environment on Windows Server 2008.

I am able to RPCPING -E okay to ensure that the vdir is setup correctly and the rpcproxy.dll responds.  I am also able to browse to

https://mail.giodivine.com/rpc/rpcproxy.dll, which results in a blank page and a valid certificate verification; however, when I attempt to ping the backend server ports for the mailbox and directory services (6001, 6002, or 6004), the RPCPING utility hangs

indefinitely (I have t ^C to break the utility).

I enabled tracing in IIS 7 for the rpc vdir and have captured a detailed failed request log for the request issued by the rpcping tool:

https://mail.giodivine.com:443/rpc/rpcproxy.dll?services.giodivine.com:6001.  There are a ton of things going on here, but I haven't been able to make anything of it.

I've even attempted uninstalling and reinstalling the RpcProxy as well as the CAS; nothing seems to help.  IPv6 is disabled, the hosts file has been updated and the certificate (mutual auth.) all seem to work correctly.

I'm at a complete loss as the RpcPing tool hangs, and I can' derive any further information about what could be going on.  Anyone able to offer some insightful ideas?

Not applicable
Ditto here .... everything worked fine with OA and OAB using NTML to IIS on CAS servers UNTIL upgrade to W2K8 .....  then we suffered thorough authenticode issues with HFR3 and then the IPv6 issue .... which since it is was not widely acknowledged or very well documented from the product team(s), caused me to scratch and load twice for no reason ..... support from MS on this issue has been weak as well .... no guidance except for the EHLO site a a TechNet article. How about a KB or a DCR or a hotfix?
Not applicable
I've been trying to get this working on our new E2K7 server for about a week and finally got it up and running with a WildCard Cert containing the SAN names for all possible iterations of connecting to my Exchange server... i.e. mail.domain.com, mail2.domain.com, mail3.domain.com, webmail.domain.com, netbiosname.domain.com, netbiosname, autodiscover.domain.com

I found this site to be very helpful in leading me down a path that proved successful.  http://exchange-genie.blogspot.com/2008/02/configuring-outlook-anywhere-for.html

Brief description of my setup:
Windows Server 2003 R2 Win64
Exchange 2007 SP1+RU2
Clients are a mix of Outlook 2003 and 2007

1. Bought the wildcard cert/also named a UC cert from Digicert.com <-Best company I've ever dealt with on cert purchases!

2. Installed the cert using the cert MMC.

3. Enabled the cert on all services using the Enable-ExchangeCertificate command in the EMS

4. Configured each service in the EMC to reflect the SAN name contained in the cert.
NOTE A: Since POP3 and IMAP will set the certificate to *.domain.com when you enable it in Step 2 - Changing this to mail.domain.com or whatever sub-domain you are using works fine as long as the SAN name was included in the cert installed in Step 1
NOTE B: I set the internal and external names for each service to my external name.  Don't forget to add an 'A Record' to your DNS server for the sub-domain to point to your internal Exchange server IP

5. In IIS I configured OAB 'Security Tab' to the following: Integrated Windows Authentication checked / Basic Authentication checked / Default Domain and Realm selected.

6. In IIS I configured RPC 'Security Tab' to the following: Intergrated Windows Authentication checked.

7. In the EMC - Server Configuration >  Client Access > Enable Outlook Anywhere.  Entered the sub-domain you intend to use and that it is included in the SAN names contained within the cert. Selected SSL offloading - Click OK.

8. After waiting the 15 minutes for it to propagate the changes or restarting the Exchange Service Host, you can verify that your changes worked by running this command in the EMS - Get-OutlookAnywhere and you should see something similar to the following:
ServerName                 : ServerNetBIOSName
SSLOffloading              : True
ExternalHostname           : mail.domain.com
ClientAuthenticationMethod : Ntlm
IISAuthenticationMethods   : {Ntlm}

9. In Outlook I configured Email accounts>Exchange Server Settings>Microsoft Exchange Server>
*Security Tab: Logon network security=Password Authentication(NTLM)
*Connection Tab: Exchange over the Internet>Connect to my Exchange mailbox using HTTP>Exchange Proxy Settings
-Enable Connect using SSL only
-Fast and Slow networks Enabled
-Proxy authentication settings:NTLM

After starting outlook I'm no longer prompted for authentication and can verify I'm connected via HTTPS by holding CTRL and right clicking on the Outlook icon in the system try and then selecting Connection Status.

Hope this helps someone and if you have any questions or comments feel free to reply.

Not applicable
This is a slightly different issue, but picking up on what pufferdude said earlier:
"Yeah, I know I could use "on fast networks connect using HTTP first, then connect using TCP/IP", but that defeats the purpose... I only want HTTP used when users aren't on the LAN."

Is this correct behaviour then?
I have laptop users which have OA enabled and both those checkboxes checked ('on fast networks...' and 'on slow networks...').
But those users always seem to connect via HTTPS when on the LAN and never connect using TCP/IP. Surely this is pretty inefficient? Shouldn't outlook detect that a TCP/IP connection is available and use it?
Not applicable
Still No go for me. I cannot get outlook to open without being prompted for username/password. I have tried all suggestions.
1-CAS/HUB on Server 2008
1-CAS/HUB on Server 2008 VM ESX
1- Mailbox on Server 2008

I keep thinking i must have the permissions wrong and have tried a combination of things but no luck.
I have been able to get the autodiscoverservice running and have OOF, Free/Busy and auto configuration working..

Outlook Anywhere (rpc/http) and the continual prompting for credentials still not working.
Can someone post what permissions they have set on all the virtual web parts so i can compare
OAB (shortcut)

"Hey Folks,
As promised, here's an update on the reprompting issue that many of you have encountered.
The gist of the issue is that IIS7 uses kernel mode windows authentication by default. Turning this off will fix reprompting. I will post a detailed update once I dig through some more and talk to the IIS PD, but for now I wanted to provide this update so you can give it a shot and let me know if (no, "that") it works for you

Here's the command that needs to be run on the CAS boxes ->
%Windows%inetsrvappcmd.exe set config /section:system.webServ
er/security/authentication/windowsAuthentication /useKernelMode:false

July 24, 2008 8:24 PM "
Not applicable
I the issue i was having was internally. I had to set all internal URL's to serverFqdn. The culprit was OAB virtual directory I had to set on Windows Authentication....but when i do get Outlook Anywhere working I have a feeling that those permissions will need to be changed for OAB to work externally..
Not applicable
Deavon, can you send out a copy of your IIS log as you ran the rpcping ? (sidm@microsoft.com). What version of rpcping are you using ? What is the configuration of your mailbox servers. They aren't behind a loadbalancer are they ? What's services.giodivinecom .. a VIP ?

Nikon, the fix for the IPv6 issue will be available in RU4. The fix for the kernel mode issue will be available shortly thereafter.

Jamie, as you and pufferdude point out, the real issue is the Outlook delay to fallback from TCP to HTTPS. A simple TCP check to a server is insufficient since the protocol could be blocked at multiple levels. So, full connecitivity must be established, and if that fails using TCP fallback to HTTP. I suspect the logon for each connection imposes some overheads causing the fallback to be slower than a quick ping.

Plazaai, what auth method are you using ?
Not applicable
Hi all

I've been trying to get this to work for weeks now!!! :-(

1 CAS/MBX on Windows Server 2008 (64-bit)
1 HUB on Windows Server 2008 (64-bit)
1 DC on Windows Server 2008 (64-bit)
1 EDGE on Windows Server 2008 (64-bit) in DMZ


FQDN for CAS/MBX server: exchcms.mydomain.local

Public domain:

Got a CA from DigiCert with:

Installed an enabled certificate with IP.W.

I did the fix regards TCP/IPv6.
I also did the: %Windows%inetsrvappcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false

I can connect with Outlook on IMAP and OWA works fine.

When i try to connect Outlook with autodisover, I get reprompt for username/password, then I get a response back, that I'm not connected to the Exchange server on exchcms.mydomain.local??
I would expect that it would say no user or connection to mail.mydomain.dk, since thats the URL I enter.
If I do a manual setup, it's the same - no connection to Exchange server, Outlook tells me.

Any help??

Not applicable

Hold in the CTRL key and right click on the Outlook icon in your system tray.  This will show some advanced options in the context menu, one that will say "Test Email AutoConfiguration."  Underneath the E-mail Address and Password text-boxes, there should be three checkboxes.  Ensure that only the first one is checked, marked "Use AutoDiscover."  Then hit the Test button.

This will verify that you have the IIS 7 autodiscover virtual directory configured properly, that your certificate contains a subject alternative name for the autodisover virtual directory if you require SSL, and that you have properly configured the Client Access URLs for internal/external access appropriately.

If you are able to connect to the autodiscover service, the test will load an XML file that contains the appropriate URLs and authentication requirements.  If you can, send me a copy of the XML (dmccaffery@giodivine.com) for further analysis and we'll go from there!

Good Luck!