Why is Communicator prompting me for credentials?



Summary:


 


When signing-in to Office Communications Server 2007 using cached Domain Credentials (e.g. you login to your corporate domain-joined laptop at home), Office Communicator 2007 may prompt you with an additional authentication dialog box:


 



 


 


 



Details:


 


When Office Communicator 2007 signs in, it also attempts to retrieve availability data via Exchange 2007 Web Services.  It does so by leveraging the Autodiscover functionality built into olmapi32.dll’s HrGetAutoDiscoverXML function. 


 


Communicator will issue SOAP requests (over HTTPS) to the published Autodiscover (*1) server, who returns the URLs for the Microsoft Exchange 2007 Client Access Server(s) that will feed the availability data back to Office Communicator.


 


The additional prompt for authentication stems from Communicator being hard-wired to authenticate using NTLM.  When IIS (on the Exchange 2007 CAS machines) returns it’s WWW-Authenticate headers, it does so in the form of:


 


WWW-Authenticate: Negotiate


WWW-Authenticate: NTLM


 


 


When Communicator attempts to negotiate authentication using your cached credentials (over the Internet), it will fail with a “401.2 Unauthorized” (*2), and subsequently prompt you for authentication as above.  However, if we force NTLM from either the client side or the server side, we eliminate these additional prompts for credentials.


 


 



Client-side fix:


 


After de-selecting “Enable Integrated Windows Authentication” (*3) in Internet Explorer (Tools, Internet Options, Advanced, scroll down to the “Security” section), you should no longer receive the additional authentication prompt from Office Communicator 2007 (to retrieve availability + out-of-office data via Autodiscover / Exchange Web Services.


 


This checkbox & the wording is admittedly a bit misleading in that it DOES NOT turn on/off NTLM; it simply controls whether Internet Explorer and the underlying Win32 API will perform security negotiation against IIS (that is Kerberos or NTLM; checkbox enabled), or simply default to NTLM (checkbox disabled).


 


This is the registry location/value that this checkbox controls:


 


HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings


Name: EnableNegotiate


Type: REG_DWORD


Data: 0 (Disabled, unchecked in the UI) or 1 (Enabled, checked in the UI); default is Enabled


 


 



Server-side fix:


 


Essentially, we are instructing IIS on the Exchange 2007 CAS server(s) to offer NTLM as the first authentication provider (with Negotiate as the fallback provider) in the WWW-Authenticate header.


 


 


For Internet Information Services 6.0:


 


1. On the Exchange 2007 CAS machine(s), start -> run -> cmd -> OK.  Change to the C:\Inetpub\AdminScripts directory.


 


2. Execute the commands below …


 


    a. Inspecting current status:


 


C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders


Microsoft (R) Windows Script Host Version 5.6


Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.


 


The parameter “NTAuthenticationProviders” is not set at this node. (*4)


 


 


    b. Setting the parameter:


 


C:\Inetpub\AdminScripts>cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders “NTLM,Negotiate”


Microsoft (R) Windows Script Host Version 5.6


Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.


 


NTAuthenticationProviders       : (STRING) “NTLM,Negotiate”


 



   c. Verifying the output:


 


C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders


Microsoft (R) Windows Script Host Version 5.6


Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.


 


NTAuthenticationProviders       : (STRING) “NTLM,Negotiate”


 


3. Restart the IIS Admin Service (which will restart all dependent services) on the Exchange 2007 CAS machine(s).


 


 


For Internet Information Services 7.0: (*5)


 


Lists configuration
appcmd list config /section:windowsAuthentication 


 


Removes Negotiate
Appcmd.exe set config /section:windowsAuthentication /-providers.[value=’Negotiate’]


 


Adds Negotiate
appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /+”providers.[value=’Negotiate’]” /commit:apphost


 


Lists configuration
appcmd list config /section:windowsAuthentication 



Here is a list of the results:


 


C:\Windows\System32\inetsrv>appcmd list config /section:windowsAuthentication
<system.webServer>
  <security>
    <authentication>
      <windowsAuthentication enabled=”true” useKernelMode=”false”>
        <providers>
          <add value=”Negotiate” />
          <add value=”NTLM” />
        </providers>
      </windowsAuthentication>
    </authentication>
  </security>
</system.webServer>


 


C:\Windows\System32\inetsrv>Appcmd.exe set config /section:windowsAuthentication /-providers.[value=’Negotiate’]


 


C:\Windows\System32\inetsrv>appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /+”providers.[value=’Negotiate’]” /commit:apphost


 


C:\Windows\System32\inetsrv>appcmd list config /section:windowsAuthentication
<system.webServer>
  <security>
    <authentication>
      <windowsAuthentication enabled=”true” useKernelMode=”false”>
        <providers>
          <add value=”NTLM” />
          <add value=”Negotiate” />
        </providers>
      </windowsAuthentication>
    </authentication>
  </security>
</system.webServer>

 





 


 



Server-side fix (specific to Exchange 2010):


 



I had a customer report (my sincere thanks, Elan Shudnow!) that their OAB wasn’t working externally.  Once they fixed the OAB, the [Communicator Credentials] prompt went away and other users reported it went away for them as well.


 


 


 


References:


 


(*1) “Overview of the Autodiscover Service”


http://technet.microsoft.com/en-us/library/bb124251.aspx


 


(*2) “401.2 Denied by Server Configuration”


http://blogs.msdn.com/david.wang/archive/2005/07/14/HOWTO_Diagnose_IIS_401_Access_Denied.aspx


 


(*3) “Integrated Windows Authentication (IIS 6.0)”


http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true


 


(*4) This is expected output as per http://support.microsoft.com/kb/215383


 


(*5) Big thanks to Jason Dozier for the IIS7 instructions 


 

Comments (42)

  1. Thanks for this – I was looking all over for this solution!  I see the Communicator 2007 R2 does not generate the prompt at all, so I guess the authentication has changed somewhat in that release.

    Thanks again!

  2. Tom Pacyk says:

    I have a client with a similar issue that I managed to duplicate in a lab setup.

    Short version is they are using Kerberos Constrained Delegation from ISA to Exchange for Outlook Anywhere with clients authenticating with NTLM via ISA 2006. Works beautifully. Deployed OCS 2007 and the Edge infrastructure and all the features work as expected with one small hiccup – external, domain joined clients repeatedly get prompted to authenticate to Exchange Web Services, but they never can successfully authenticate so there’s an auth mismatch at some point. Having trouble figuring out where. Every single component of Exchange works great inside and outside so I know Autodiscover, EWS, UM and OAB are working fine.

    Integrated Auth is enabled on the CAS for both the EWS and Autodiscover virtual directories. I’ve tried flipping Basic auth on both, or just one or the other and unsuccessfully. The client either gets the endless authentication or it just fails altogether without prompting.

    My next step would be to try flipping the authentication provider method around as you indicated as the server-side fix. Any potential issues on the Exchange side with that adjustment?

    Any other suggestions?

  3. scottos says:

    Hi Tom,

    In terms of reversing the WWW-Authenticate headers provided by IIS (via Exchange CAS), our customers have found no ill side effects, and this workaround has been deployed repeatedly.

    I hope this resolves your issue, and if not, feel free to contact me (via the contact form), and we’ll go from there.

    Scott Oseychik

  4. Henrik Garpenrud says:

    Hi, this server-side fix is setting this on the Exchange CAS. But what about if we have an ISA in between? I have the exact same setup and errors as Tom.

    Thansk in advance

  5. Scott says:

    Now sure how to make this change in ISA, but you can use a combination of our STRACE and HttpReplay utilities to find how the WWW-Auth header is being received via the client:

    Strace:

    http://www.microsoft.com/downloads/details.aspx?familyid=f5ec767f-27f2-4fb3-90a5-4bf0d5f4810a&displaylang=en

    Once you install it, open a cmd prompt, change to "C:Program FilesSTRACE" and issue the following command:

    withdll /d:STRACE.dll_IE7 "C:program filesmicrosoft office communicatorcommunicator.exe" (or whichever .exe you’re trying to trace; but in this case, communicator.exe)

    HttpReplay:

    http://www.microsoft.com/downloads/details.aspx?familyid=d25ba362-c17b-4d80-a677-1faff862e629&displaylang=en

    Take the logfile generated by Strace (default: it goes on the Desktop)

    Move it to the C:Program FilesHttpReplay directory

    Open a cmd prompt, change to C:Program FilesHttpReplay

    Issue the following command:

    Httpreplay <yourfilenamehere.log>

    Presto!  You should have a nice pretty webpage with all the relevant info.  🙂

    Scott Oseychik

    Senior Escalation Engineer

    Microsoft, Unified Communications Team

  6. Henrik Garpenrud says:

    Hi Scott, thanks alot for your quick answer.

    Could it complicate things that i run IE8 on Vista SP2_RC? Because strace doesnt seemt to collect any information.

    If i do the client-side fix, i don’t get thet popup, but rather a "Exchange Connection Error". It can’t access the OAB/OOF… but Outlook can, perfectly..

    Thanks in advance

  7. Scott says:

    Hi Henry,

    I haven’t tried Strace/HttpReplay with IE8 + Vista SP2 RC, but I suspect you’re correct.  Was trying to save you the hassle of breaking out Network Monitor (or Wireshark).

    My recommendation is to engage Microsoft Customer Support Services via http://support.microsoft.com & we’ll get it figured out.  🙂

    Regards,

    Scott Oseychik

  8. SSL74 says:

    Hi

    Nice article. Exactly what i am looking for.. but it’s not working for me.

    I’m connected by VPN. Opening Outlook 2007 doesn’t prompt me anything. Autodiscover service test is Ok.

    Oh yeah. OCS is installed on Windows 2008.

    Opening communicator asks me for basic authentication window, but the olf fashionned-one (looks like an IIS6 authentication dialog box, not the one you screenshooted).

    Tried the strace tool and so one, but really don’t get how to use this trace. Can you be any help ?

    Thak you ^^ 🙂

  9. Christian says:

    Hi,

    This did not fix my issue. I publish Outlook Anywhere with ISA.

    I followed your article, the only thing that is different now is following:

    <windowsAuthentication enabled="false">

    in your example

    <windowsAuthentication enabled="true" useKernelMode="false">

    Rest of my config

    C:WindowsSystem32inetsrv>appcmd list config /section:windowsAuthentication

    <system.webServer>

     <security>

       <authentication>

         <windowsAuthentication enabled="false">

           <providers>

             <add value="NTLM" />

             <add value="Negotiate" />

           </providers>

         </windowsAuthentication>

       </authentication>

     </security>

    </system.webServer>

    How can I change it ? Everything else is working perfectly. But I still get the Outlook Integration login. Can it be the windowsAuthentication config.

    Christian

  10. scottos says:

    I’d try using Strace & HttpReplay to dig deeper into this:

    Strace:

    ———

    http://www.microsoft.com/downloads/details.aspx?familyid=f5ec767f-27f2-4fb3-90a5-4bf0d5f4810a&displaylang=en

    – Once you install it, open a cmd prompt, change to "C:Program FilesSTRACE" and issue the following command:

    withdll /d:STRACE.dll_IE7 "C:program filesmicrosoft office communicatorcommunicator.exe" (or whichever executable you’re going to trace)

    HttpReplay:

    —————

    http://www.microsoft.com/downloads/details.aspx?familyid=d25ba362-c17b-4d80-a677-1faff862e629&displaylang=en

    – Take the logfile generated by Strace (default: it goes on the Desktop)

    – Move it to the C:Program FilesHttpReplay directory

    – Open a cmd prompt, change to C:Program FilesHttpReplay

    – Issue the following command:

    Httpreplay <yourfilenamehere.log>

    Presto!  You should have a nice pretty webpage with all the relevant info.  🙂

    Hope this helps,

    Scott Oseychik

  11. Tony Bennett says:

    I have the very same problem Tom Pacyk had, with domain joined clients (using KCD via ISA, which work fine), and non domain joined clients all via ISA, but I’ve not been able to resolve the problem at all.

    What im getting is that when I open communicator client, it fires the login for the mailbox, followed by an autodiscover prompt. When I look the report generated by srace/htpreply, I see that the client is tryingto mame a post to https://autodiscover.domainname/autodiscover/autodiscover.xml. Autodiscover is published via ISA, and if I open Outlook, everything appears to work ok (out of office etc).

    I also tried the netiotation methods in IIS (NTLM, negotiate, mentioned at he top of the article), but no luck there at all. After some very late nights, I’m at my wits end with it, and am close to having to raise a call with Microsft, but wanted tp post here first to see if anyone had any other ideas.

    Whatever logs need to be posted here, i’ll gladly supply.

    Hope you can help!

    Thanks

  12. Scott Oseychik says:

    Hi Tony,

    Unfortuantely, the scenario I debugged did not involve ISA (and nor do I claim to be an ISA expert by any means); I think we definitely need to fully understand & resolve this "twist" on the issue, as many customers seem to be hitting the same problem.

    My recommendation is to engage Microsoft Customer Support Services (http://support.microsoft.com), cite this blog entry, and we’ll help figure this one out.  I’ll be out of the office (actually, out of the country!) all next week … going onsite to debug a customer issue, but we have a very talented team in Unified Communications Support that shold be able to help nail this one.

    Regards,

    Scott Oseychik

    Senior Escalation Engineer

    Microsoft, Unified Communications Group

  13. joho0 says:

    Scott,

    Okay…MOC 2007 R2 connecting to Exchange 2007 running on Server 2008 x64 (IIS7). All is well except for this "Exchange Connection" issue. I implemented your client side fix and voila! Problem Solved. I then reverted that back (cause who wants a client side solution?) and then implemented the server side fix and…fail. I still get the same behavior as before. I even did an iisreset just to be certain. Still no love. Any ideas?

    Thanks,

    John

  14. Scott Oseychik says:

    Hi John,

    Are you running straight IIS7, or do you also have IIS6 compatibility installed as well?  I may have more testing to do w/straight IIS7 …

    Thanks,

    Scott Oseychik

  15. joho0 says:

    4 days. That’s what it took to fix this and in the end, I should’ve tried this first. For all those struggling, here’s what I had to do…

    First, some info:

    Server A: Windows Server 2008 x64 SP2 w/ OCS 2007 R2 Enterprise (consolidated FE server)

    Server B: Windows Server 2008 x64 SP2 w/ Exchange 2007 Enterprise SP1

    Client: Vista x64 Business SP2 w/ MOC 2007 R2

    Okay, client logs into MOC no problem, but gets the dreaded "Exchange Connection" error. MOC need to connect to exchange to get address book info. MOC uses exchange autodiscover to learn exchange OWA URL (using user’s SIP login domain to query DNS for autodiscover SRV record). Ours is using an external URL (even internally) to avoid SAN certificate issues (one external cert for both internal and external, just always use external name for config…this works…no problems here). But MOC insists on using NTLM auth and is connecting to Exchange using external URL. If HTTP SPN doesn’t exist for exchange server object in AD-DS using the external URL  (HTTP/externalurl.domain.com), then NTLM will fail.

    I used the following command to remedy:

    setspn -A HTTP/<external.domain.url> <exchangeNETBIOSname>

    Just substitute the external URL FQDN and the exchange server name (just hostname…not FQDN) where specified.

    Enjoy!

  16. Scott Oseychik says:

    joho0: Great work!!  Please contact me via http://blogs.msdn.com/scottos/contact.aspx … I’d like to discuss further.

    Thanks,

    Scott Oseychik

  17. joho0 says:

    Sure thing Scott.

    I just wanted to point out one huge error with my previous post. Everywhere I mention NTLM, just go ahead and substitute Kerberos. I know this is contrary to what you stated in your post, but my experience has been that NTLM is failing for unknown reasons and that only by fixing Kerberos (with the SPN entries in AD) was I able to resolve this issue. I know this to be true, and it took a few minutes to dawn on me, because Kerberos uses SPNs and NTLM doesn’t, and that’s the only thing I changed.

    That would explain why forcing NTLM by switching off negotiate on the server side offered no help. Not sure why turning off negotiate on the client side caused NTLM to work all of a sudden. This may be a clue, as there are still some unknowns at work here, but I’ve verified this solution on some other domain pcs, so I’m not going to worry much about the NTLM issue.

  18. Greg Guhin says:

    We were having the same problems in our environment.  We had tried the client side fix and it solved the issue.  The server side fix did not solve the problem.  John0’s comment got me to looking at our SPN configurations.

    We have NLB on for our CAS servers and an alias (webmail) pointing to the CAS NLB address.  I looked for the SPN entries for each host that participates in the NLB and found that only one (cashub01) had an entry for the HTTP/ SPN.  I added HTTP/webmail.mydomain.com for the second server (cashub02) and the problem was fixed.

    Thanks to everyone contributing on this thread.

  19. Tim says:

    We attempted the client side fix, however all intranet and SSO pages now failed to load.  Haven’t attempted the server side fix yet, will report back when we do.

  20. Mike Baker says:

    we have two issues open with MS at the moment both related to outlook and communicator password prompts.

    We are using ISA with pre-auth which requires basic authentication on the back end.

    Outlook clients configured with RPC/HTTP on a cluster failover will prompt for password – outlook "design" and is the same in o2010.

    which brings me on to Communicator Client – because you cannot switch off the autodiscover on the client so you get  prompted for a password once again..

    I’m betting alot of money that MS cannot solve this with ISA configured to provide pre-auth in a DMZ.. engineering failure to integrated communicator and outlook effectively.

  21. scottos says:

    >> I’m betting alot of money that MS cannot solve this with ISA configured to provide pre-auth in a DMZ.. engineering failure to integrated communicator and outlook effectively.

    Exactly how much money are we talking here? 🙂

    Regards,

    Scott Oseychik

  22. Dillon Bussert says:

    Scott, I have a similar, but possibly different problem.  I have a non-domain joined computer accessing Exchange with Outlook 2007 and Communicator 2007 using my username.

    I get constant prompts for credentials when signed into Communicator, tried the client-side fix you suggested and it did not work.  The popup says "Connect to webmail.[domain].com" in the header and "Connecting to autodiscover.[domain].com" and provides my username and blank password.  Entering my password does not login and I have to cancel the prompt.

  23. scottos says:

    Here’s a hack:

    1. Start -> Run -> "control keymgr.dll" (no quotes) -> OK

    2. Enter your domain credentials (YOURDOMAINusername)

    3. For the domain, enter *.yourdomain.com

    4. Reboot

    Now, anytime you try to access autodiscover.domain.com, webmail.domain.com, etc., the OS will automatically pass along your domain credentials w/o prompting for auth.

    Regards,

    Scott Oseychik

  24. Tom Pacyk says:

    Mike, you can do pre-auth with ISA through KCD with a few more hotfixes and changes. See my post from last year for more details: http://www.confusedamused.com/notebook/office-communicator-outlook-integration-error-problems-when-using-isa-2006-and-exchange-kerberos-constrained-delegation/

  25. Scott Oseychik says:

    Awesome to see the community experts helping each other!  Thanks for the tip, Tom!

    Regards,

    Scott Oseychik

  26. Stephane Delisle says:

    We are using OCs 2007r2 and ISA for external AB. The setspn command from joho0 fixed our problem company wide.

    Thanks

  27. jaskis says:

    1) Windows Auth is intended to work only in INTRANET environment and it is not designed for internet

    2) Secondly "NTLM,Negotiate" id not valid entry

    Possible value are:

    "Negotiate,NTLM" OR none (default)

    "NTLM"

  28. ozgurc says:

    Hi Scott,

    Thanks for the article. as previosuly mentioned this doesnt solve the issue when isa is deployed as reverse proxy. However theres another perfect artcle that describes how to overcome that issue.

    http://www.confusedamused.com/…/office-communicator-outlook-integration-error-problems-when-using-isa-2006-and-exchange-kerberos-constrained-delegation

    My question is if the resolution applies for TMG aswell or how can i find out about it.

  29. Scott Oseychik says:

    Hi ozgurc,

    Unfortunately, I don't know the answer offhand, but our crazy-talented team of Support Engineers in OCS should be able to assist; http://support.microsoft.com … thanks!

    Regards,

    Scott Oseychik

  30. Hi Everyone,

    Great thread ! Unfortunately it seems that all the posts are realted to clients joined to a domain that hosts both Exchange AND OCS.

    In our environment, we have corporate laptops which are members of the corproate domain which hosts the Exchange service. MOC 2007 R2 is installed on all clients but the OCS 2007 R2 service is hosted in a different single domain forest (we are using the Microsoft dedicated hosted OCS service). There are no trusts.

    Expected Behaviour (or so I thought until actual deployment) :

    1. User logs on to laptop internally with domain credentials.

    2. User launches Outlook and is NOT asked for credentials (as its the same domain).

    3) User launches MOC, and enters totally different set of credentials and connect perfectly.

    4) As the Email address in Domain1 user account (used for Exchange) and Domain2 user account (OCS Server) are configured as the same, presence works in Outlook.

    5) BUT, the dialogue prompt for exchange credentials pops up. If enetered (credentials from Domain 1) everything works perfectly.

    Questions :

    A) Where is the "Save Password" tick box in this dialog box ? Please don't tell me there isn't one ? Can it be forced to appear throught he regsitry just like the MOC Save Password check box ?

    B) What can be done to get the laptop credentials to be used automatically when MOC tries to talk to the Exchange server ? Or……

    C) Is this always going to be experience for all our users if OCS is in a diff domain to the one that houses the client PCs and Exchange.

    Please help. If the stuff int his thread applies to us too, great. If someone can let me know, then I can attempt to deploy in our lab.

    Many Thanks,

    Ish

  31. Zachary Loeber says:

    I'd like to add my two cents on this issue. I did the recommendation you posted but my issue was not resolved. The difference is that I'm utilizing 2 CAS servers behind an F5 load balancer. The comments in this post can be misleading for people in my shoes so I hope people read to the end and find my warnings 🙂

    So people recommend using setspn to add a service principal name for the cas server to help fix the autodiscover prompting. Do NOT do this in a load balanced situation as you can only have one spn per account in AD otherwise duplicates defeat the purpose of having the spn (to uniquely locate a service in AD for kerberos authentication). If you do want kerberos you need to setup a shared service account to use via this complicated procedure: technet.microsoft.com/…/ff808312.aspx

    To fix this in a cas array where you are not implementing kerberos for autodiscover and web services MAKE SURE TO DELETE ALL HTTP SPNs.

    If an HTTP spn is showing when you run setspn -L <servername> then just go ahead and remove it, (setspn -D http/autodiscover.contoso.com casservername). Yup remove them all. Then things will start to use NTLM authentication instead of trying Kerberos and giving annoying autodiscover prompts.

    Hope this helps someone as I never ran across this in any deployment documentation from either F5 or Microsoft or anyone else.

    Zach

    http://the-little-things.net/

  32. scottos says:

    @Zach,

    Thank you VERY MUCH for your detailed post here!  I'm sure it'll help others out … much appreciated!

    Regards,

    Scott Oseychik

  33. Hello Scott says:

    Interested to know if this case is also valid when using Lync (srv+client)+e2010? Anyone seen this when using Lync. I'm but can it be the same case.

    -Timo-

  34. Gerhard Wessels says:

    Greetings.

    I applied the settings above to no avial.

    I followed this article:

    blogs.technet.com/…/default-authentication-settings-exchange-2007-2010-iis-application-virtual-directories.aspx

    And found I had digest authentication enabled on EWS, and not just windows authentication.

    Once I cleared it and reset IIS my lync clients are no longer prompting for authentication.

    Hope that helps someone!

  35. scottos says:

    Thanks for the feedback, Gerhard!  Hope others find your findings helpful, also!

    Regards

    Scott Oseychik

  36. Saamee says:

    I'm still facing the issue with the credentials for calendar retrival. I have done the changes on the server. We are running with Exchange 2010 and Lync 2010 as well OCS2007 r2..can some one share your thoughts

  37. scottos says:

    Hi Saamee,

    If all the obvious things have been tried already (including some of the valuable additions that others have left here in the comments), my recommendation would be to formally engage Microsoft Customer Support Services so we may resolve this issue with you.

    Regards,

    Scott Oseychik

  38. Saamee says:

    Scott i just changed the EWS providers to NTLM and now i'm not getting prompted for the "Retriving data from Calendar" ….Hipp Hipp hooorreyyy…Good article

    regards

    Saamee

  39. scottos says:

    Glad the workaround resolved your issue, Saamee!

    Regards,

    Scott Oseychik

  40. I'm getting the prompt however changing the setting within ie isn't helping.  HTTPreplay is telling me i'm getting 401 on the EWS address.  I'm using TMG to publish EWS/Exchange and ISA in another site which is doing the traffic routing to OCS.  If I use a hosts file to point the EWS address (same cname as exchange proxy server addr) from the TMG publishing rule to the 2010 CAS I get no integration errors.  Any ideas?

    -chris

  41. Vinay Mishra says:

    Dear All,

    I have not checked much into the Issue as discussed in the article. Just now seen this article.

    Problem:

    Users are getting Password prompt mentioning "connecting to <email-id>" in both communicator and outlook.

    Observations:

    1. Most users are using outlook anywhere with Basic Authentication in client.

    2. We have just migrated to Exchange 2010.

    This issue is eating my head since last 15 days. Done many Fine-tuning but no luck yet. Please suggest me.

    Regards,

    Vinay Mishra

    mail: vinay5m@ymail.com