Exchange Server TechCenter > Exchange Server Forums > Deploy > Outlook Anywhere issues with Exchange 2007

Answered Outlook Anywhere issues with Exchange 2007

  • Monday, July 21, 2008 7:30 PM
     
     

    Hi Everyone.

    So, I am in the process of creating an exchange 2007 server for our company. I have everything working internally and OWA works fine externally. The problem is I cannot configure Outlook externally to connect to the exchange server VIA RPC over HTTPS. When external, i get 'server cannot be resolved' error messages after it prompts me for user name and password multiple times. I can access all the websites (autodiscover.xml, ews etc.) externally through IE after entering a valid user name and password but cannot access the /rpc website (it just keeps asking for credentials). My set up is a little something like this:

    - PDC, global catalogue server

    - exchange server joined to the domain as a member server

    - i purchased an SSL certificate for exchange.myextdomain.com

    - i have changed all of the virtual directories to use exchange.myextdomain.com\therest

     

    when i run a 'test-outlookwebservices | fl' from EMC i get the following returned:

    Id      : 1003
    Type    : Information
    Message : About to test AutoDiscover with the e-mail address admin@myextdomain.com.

    Id      : 1007
    Type    : Information
    Message : Testing server myserver.myintdomain.local with the published name https://exchange.myextdomain.com/EWS/Exchange.asmx & .

    Id      : 1019
    Type    : Information
    Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://exchange.myextdomain.com/Autodiscover/Autodiscover.xml.

    Id      : 1013
    Type    : Error
    Message : When contacting https://exchange.myextdomain.com/Autodiscover/Autodiscover.xml received the error The remote server returned an error: (401) Unauthorized.

    Id      : 1006
    Type    : Error
    Message : The Autodiscover service could not be contacted.

     

    yet i can log into the autodiscover web site fine internally and externally using https://exchange.myextdomain.com/Autodiscover/Autodiscover.xml

     

    In IIS, i have only 'basic' and 'windows integrated' authentication for all of these web services. the certificate works perfectly for OWA, i have an A record setup in DNS for autodiscover and have also tried a CNAME for autodiscover .

     

    Can anyone see where i am going wrong here, this is driving me insane i tells ya.

    Thanks a lot for any help

    Colin

     

Answers

  • Monday, December 08, 2008 3:26 PM
     
     Answered

    Hi Everyone.

     

    So i just got off the phone with MS tech support. 3 Hours later we had the fix. Here are the main points that resolved this issue.

     

    On our PDC & BDC:

    - We added the 'NSPI interface protocol sequences' registry key[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters] and rebooted

     

    On our exchange server:

    -       We added another registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

    Value Name: MaxWorkItems

    Data Type: REG_DWORD

    Value data: 8192 (decimal)

     

    -       Ran IISRESET and restarted the System Attendant service.

    -       Now, the username resolves while configuring a profile and Outlook connects on HTTPS without errors.

     

    This MaxWorkItems key seems to be the one that fixed the issue.

     

    Hope it helps for anyone else who may be having this issue.

    Thanks to everyone for their help.

     

    Colin

     

     

All Replies

  • Wednesday, July 23, 2008 9:38 AM
     
     

    i had facing this issue before,something look like similar with your.

     

    after deploy the SSL/HTTPS, similar with you are facing, keep asking ID and password even is valid.but once i take out the SSL/HTTPS it work fine. perhaps you can try to access your OWA with out SSL/HTTPS. if can access,maybe is the SSL issue or somewhere setting issue. hope it can help you.

     

     

     

     

  • Wednesday, July 23, 2008 9:46 AM
     
     

     

    Hi Colin,

     

    I suggest that we attempt the following method to troubleshoot the issue:

     

    1.    Please firstly ensure the client is configured correctly. You can refer to following site:

     

    http://www.msexchange.org/tutorials/outlookrpchttp.html

     

    2.    Please ensure that no certificate related error is encountered when accessing OWA through the problem external client. I would like to explain that IE does have a mechanism to allow browsing of sites that do not contain valid certificates but RPC over HTTPS does not.

     

    Note: I assume the OWA and RPC virtual server on the same Web Site.

     

    3.    Use RPCPing on the client to ping the rpcproxy server:

     

    RPCPing.exe –t ncacn_http –o RpcProxy=<the external host name of Outlook Anywhere> -u=10 –a connect –v 3 –E –R <HTTP Proxy Server or none> -P “username,domain,password” –H 1 –F 3 –b

     

    Please let me know whether you can ping the rpcproxy server successfully. Please also remember the Server Certificate Subject gathered by the command and ensure the principal name which you configured in the Outlook profile is same as one gathered by running the above command.

     

    If the command failed, please post the result here.

         

          Regarding more information of RPCping, please refer to the following site:

          http://support.microsoft.com/kb/831051

     

    4.    The command in step 3 is to verify user by using Basic Authentication method. If you can ping the rpcproxy server successfully by using the command, I suggest that you modify the configuration of Outlook Anywhere and RPC virtual server to user Basic Authentication method (Please uncheck the Integrated Windows authentication method in IIS). Please also modify the Outlook profile setting to use Basic Authentication.

     

    Mike

     

  • Wednesday, July 23, 2008 1:40 PM
     
     
    Hoong, Thanks for your reply. But, my OWA is working perfectally internally and externally with my SSL certificate. The browser reports no errors.

     

  • Wednesday, July 23, 2008 1:43 PM
     
     

    Mike,

    thanks a lot for the suggestions. My outlook client is configured correctly and OWA is working perfectly internally and externally with my SSL cert, and yes OWA and the RPC virtual server is on the same web site. I will try the RPCping utility and let you know my results.

    Thanks again

    Colin

     

  • Wednesday, July 23, 2008 4:15 PM
    Moderator
     
     

    Hello Colin,

     

    Does this help you? Symptoms look similar if I understood correctly.

     

    Autodiscover Service Returns Unexpected Values for Outlook Anywhere Proxy Settings

  • Wednesday, July 23, 2008 4:23 PM
     
     

     

    Mike,

    Here my RpcPing output:

     

    C:\Users\Colin>rpcping -t ncacn_http -s exchange.myextdomain.com -o RpcProxy=exchange.myextdomain.com -P "cstewart,myintdoman.local,*" -H 1 -u 10 -a connect -F 3


    Enter password for RPC/HTTP proxy:

    Exception 1722 (0x000006BA)
    Number of records is: 2
    ProcessID is 960
    System Time is: 7/23/2008 16:14:20:133
    Generating component is 14
    Status is 1722
    Detection location is 1398
    Flags is 0
    NumberOfParameters is 2
    Long val: 4
    Long val: 1722
    ProcessID is 960
    System Time is: 7/23/2008 16:14:20:132
    Generating component is 13
    Status is 1722
    Detection location is 1418
    Flags is 0
    NumberOfParameters is 0

     

    Any ideas??

    Thanks

    Colin

  • Wednesday, July 23, 2008 4:54 PM
     
     

    Hi Mike, Further to my last post, i added the -E switch to the end of the command and this was returned:

     

    Enter password for RPC/HTTP proxy:

    Checking IE setting ....

    The proxy setting is disabled

    Pinging successfully completed in 1014 ms

     

    Que pasa?

    Thanks

    Colin

  • Thursday, July 24, 2008 5:15 AM
     
     

     

    Hi Collin,

     

    Thanks for the information.

     

    From the RPCPing test, I understand that you can pass the Basic authentication on the RpcProxy server. Base on the current situation, please add the –b parameter at the previous command. We should receive the server certificate information.

     

    Please ensure the msstd value which you get from the command is same as the one which you configured on the user profile.

     

    In addition, would you please configure the Outlook Anywhere to use Basic Authentication method instead of the NTLM authentication method to test the issue?

     

    By the way, please let me know whether Exchange 2007 Service Pack 1 has been installed on the CAS server.

     

    1.    On the Client Access Server, configure the Outlook Anywhere to use Basic Authentication

    2.    On the IIS Admin, please uncheck Integrated Authentication method for RPC virtual directory

    3.    On Outlook Profile setting, Use Basic Authentication method when connecting to rpcproxy server

     

    If the issue still persists after modifying the authentication method, please attempt the following method to test the connection between the rpcproxy server and mailbox server.

     

    Step 1: Run RPCcfg on the rpc proxy server to check whether the correct port has been configure on the RPC proxy server:

     

    Rpccfg.exe /hd

     

    Note: The Rpccfg tool is included in the Windows Server 2003 resource kit

     

    Step 2: Verify Client can contact backend port by using RPCping on the external client:

     

    RpcPing –t ncacn_http –s ExchangeMBXServer –o RpcProxy=RpcProxyServer –P “user,domain,password” –I “user,domain,password” –H 1 –F 3 –a connect –u 10 –v 3 –e 6001 –v 3

     

    RpcPing –t ncacn_http –s ExchangeMBXServer –o RpcProxy=RpcProxyServer –P “user,domain,password” –I “user,domain,password” –H 1 –F 3 –a connect –u 10 –v 3 –e 6002 –v 3

     

    RpcPing –t ncacn_http –s ExchangeMBXServer –o RpcProxy=RpcProxyServer –P “user,domain,password” –I “user,domain,password” –H 1 –F 3 –a connect –u 10 –v 3 –e 6004 –v 3

     

    Mike

     

  • Thursday, July 24, 2008 4:08 PM
     
     

    Hi Mike,

     

    Results.

    - when i add the -b to the command i ran originally i get this returned:

    "you can retrieve the server subject certificate only if you do proxy echo only"

     

    - when i add -B msstd:exchange.myextdomain.com i get this returned:

    Exception 1722 (0x000006BA)
    Number of records is: 2
    ProcessID is 3000
    System Time is: 7/24/2008 13:18:29:368
    Generating component is 13
    Status is 1722
    Detection location is 1352
    Flags is 0
    NumberOfParameters is 1
    Long val: -1073606646
    ProcessID is 3000
    System Time is: 7/24/2008 13:18:29:368
    Generating component is 14
    Status is -1073606646
    Detection location is 1380
    Flags is 0
    NumberOfParameters is 2
    Long val: 12007
    Unicode string: /rpc/rpcproxy.dll?exchange.myextdomain.com:593

     

    - Outlook anywhere is configured to use basic authentication only (server side)

    - SP1 has been installed on the exchange server

    - RPC virtual directories are set to use basic authentication only

     

    - running rpccfg /hd on the CAS returned:

    NETBIOS name  6001-2002 6004

    internal FQDN    6001-6002 6004

     

    and finally testing from the external client on those specific ports all returned essentially the same thing.

    Exception 1722 (0x000006BA)
    Number of records is: 2
    ProcessID is 3480 - this number varied
    System Time is: 7/24/2008 13:18:29:368 - this varied
    Generating component is 14
    Status is 1722
    Detection location is 1398

    Flags is 0
    NumberOfParameters is 2

    Long val: 4
    Long val: 1722
    ProcessID is 3480
    System Time is: 7/24/2008 13:18:29:368
    Generating component is 13

    Status is 1722
    Detection location is 1418
    Flags is 0
    NumberOfParameters is 0

     

    I guess all this i boiling down to the fact that i can't contact the RPC proxy sucessfully??

    Thanks again

    Colin

  • Thursday, July 24, 2008 5:08 PM
     
     

    Mike, I got the -b to work (had to use -E as well) anyways, this is what is returned. The msstd: is the same one i am trying to use when configuring Outlook externally.

     

    Server Certificate Subject: (fullsic:\<C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root>\<C=US, S=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware>\<C=CA, PostalCode=N1T 1J5, S=Ontario, L=Cambridge, STREET=our address, O=Our Company Inc., OU=Comodo InstantSSL, N=exchange.extdom.com>;msstd:exchange.extdom.com)
    Pinging successfully completed in 514 ms

     

    Thanks

    Colin

  • Friday, July 25, 2008 2:28 AM
     
     

     

    Hi Colin,

     

    Firstly, please understand that the –E parameter restricts the connectivity test to the RPC Proxy server only. As we can ping the RPC Proxy Server successfully with using –E, I believe there is no connection and authentication problem between the External Client and RPC Proxy Server.

     

    The next steps, we need to check whether the External client can connect to the mailbox server through the RPC Proxy Server successfully.

     

    Thus, please let me know whether the exception 1722 was encountered when rpcping all the three ports on the Internal mailbox server.

     

    Please also attempt the following method to troubleshoot the issue:

     

    1.    Please ensure the RPC Proxy Server is able to resolve the DNS name of the Internal Maibox Server Name to correct IP.

    2.    On the RPC Proxy server, run RPCping –t ncacn_ip_tcp –s <internal mailbox server>

    3.    On the internal mailbox server, please ensure that the correct ports have been configured:


    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters]

    HTTP Port: 6002
    Rpc/HTTP NSPI Port: 6004

    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem]

    Rpc/HTTP Port 6001

     

    4. Use RPCDump to check whether the ports are listened on the internal mailbox server

     

    RPCdump /s <internal mailbox server>

     

    Please verifying following items for the ncacn_http protocol:

     

    Information Store is listening on the port 6001

    Directory service proxy server is listening on port 6004

    Directory service Referral service is listening on port 6002

     

    Mike

  • Friday, July 25, 2008 2:53 PM
     
     

    Hi Mike,

     

    - When i pinged ports 6001,6002,6004 from the external client, exception 1722 was encountered on all of them.

    - the RPC proxy server is the same server as the mailbox server

    - running RPCping –t ncacn_ip_tcp –s <internal mailbox server> returned the following:

    Completed 1 calls in 31 ms
    32 T/S or  31.000 ms/T

     

    - all registry keys mentioned above are set correctly on the mailbox server

     

    - the following is what was returned for the ncacn_http portion of the rpcdump /s on the mailbox server

     

    ncacn_http(Connection-oriented TCP/IP using Microsoft Internet Information Server as HTTP proxy.)
      10.10.12.62[6002] [1544f5e0-613c-11d1-93df-00c04fd7bd09] MS Exchange Directory RFR Interface :NOT_PINGED
      10.10.12.62[6004] [f5cc5a18-4264-101a-8c59-08002b2f8426] MS Exchange Directory NSPI Proxy :NOT_PINGED
      10.10.12.62[6002] [3cb4be69-9ba1-448c-9a44-a1f759a1878a] MS Exchange Recipient Update Service RPC Interface :NOT_PINGED
      10.10.12.62[6002] [f930c514-1215-11d3-99a5-00a0c9b61b04] MS Exchange System Attendant Cluster Interface :NOT_PINGED
      10.10.12.62[6002] [83d72bf0-0d89-11ce-b13f-00aa003bac6c] MS Exchange System Attendant Private Interface :NOT_PINGED
      10.10.12.62[6002] [469d6ec0-0d87-11ce-b13f-00aa003bac6c] MS Exchange System Attendant Public Interface :NOT_PINGED
      10.10.12.62[6001] [5261574a-4572-206e-b268-6b199213b4e4] Exchange Server STORE Async EMSMDB Interface :NOT_PINGED
      10.10.12.62[6001] [a4f1db00-ca47-1067-b31f-00dd010662da] Exchange Server STORE EMSMDB Interface :NOT_PINGED
      10.10.12.62[6001] [da107c01-2b50-44d7-9d5f-bfd4fd8e95ed] Exchange Server STORE ADMIN Interface :NOT_PINGED
      10.10.12.62[6001] [99e64010-b032-11d0-97a4-00c04fd6551d] Exchange Server STORE ADMIN Interface :NOT_PINGED
      10.10.12.62[6001] [99e64010-b032-11d0-97a4-00c04fd6551d] Exchange Server STORE ADMIN Interface :NOT_PINGED
      10.10.12.62[6001] [89742ace-a9ed-11cf-9c0c-08002be7ae86] Exchange Server STORE ADMIN Interface :NOT_PINGED
      10.10.12.62[6001] [a4f1db00-ca47-1067-b31e-00dd010662da] Exchange Server STORE ADMIN Interface :NOT_PINGED

     

    Thanks again for your help on this, i really appreciate it.

    Colin

     

  • Wednesday, July 30, 2008 7:07 AM
     
     

    Hi Colin,

     

    I understand that the error 1722 was encountered on all the three ports.

     

    At this time, Colin, I would like to check the command firstly:

     

    RpcPing –t ncacn_http –s ExchangeMBXServer –o RpcProxy=RpcProxyServer –P “user,domain,password” –I “user,domain,password” –H 1 –F 3 –a connect –u 10 –v 3 –e 6001 –v 3

     

    In the command, as your mailbox server is same server as the RPC Proxy server, please ensure that the ExchangeMBXServer name should be the FQDN of Exchange Server. The RpcProxyServer name should be the External host name which you set in the Outlook Anywhere.

     

    In addition, I also suggest that you run the three commands on the RPC Proxy server to check the result. If you can ping the three ports successfully on the RPC Proxy server locally. I suggest that you bypass the Firewall between the External Client and the RPC Proxy Server and run the commands again on the External Client.

     

    Mike

     

  • Wednesday, July 30, 2008 4:29 PM
     
     

     

    Hi Mike,

     

    Thanks for the suggestion. I pinged the 3 ports on the RPC Proxy server locally, 6001 and 6002 returned a 'completed in ##ms'. 6004 returned the dreaded 1722 exception 

     

    I will let you know the results of the ping from the external client when i get back from holidays.....thanks again for your help so far.

     

    Colin

  • Thursday, July 31, 2008 9:53 AM
     
     

     

     

    Hi,

     

    I understand that if we ping the three ports locally. You can ping the 6001 and 6002 port but fail at 6004 port.

     

    The port 6004 is related to the Exchange NSPI DSProxy component which is a core component for Exchange Server to access AD information from GC/DC on behalf of Outlook clients.

     

    Thus, I suggest that we attempt the following method to troubleshoot the issue:

     

    1.    Please locally telnet the mailbox server on port 6004. We should receive the following information:

     

    ncacn_http/1.0

     

    2.    Increase eventlog level for Exchange System Attendant (MSExchangeSA) to expert and restart the System Attendant service. Please check application event log for detailed information. You can also send the application log to me for further check. Please remember to let me know when you restart the System Attendant service

     

    Mike

  • Wednesday, August 06, 2008 1:33 PM
     
     

    After performing the tasks mentioned in this thread, specifically making sure the server was listening on the correct ports for RCP, my Exchange server is now reporting multiple NSPI Proxy warnings in the applicaiton log (event ID 9040).  The issue has not been resolved.

  • Wednesday, August 06, 2008 8:54 PM
     
     

    Hi Mark.

     

    I have done what you suggested. I did receive the ncanc_http/1.0 message in step 1.

    i have increased the log level for the MSExchangeSA service and restarted the service. Is there something specific i should be looking for? I currently have no 'errors' for this service in the event log since i restarted it. There are a bunch of 'Information' items though.

     

    Thanks again

    Colin

  • Wednesday, August 13, 2008 1:40 AM
     
     

    Hi Colin,

     

    I understand that you can telnet to the 6004 port successfully and no error is received when reboot the System Attendant Service.

     

    Regarding the issue, please let me know whether any Windows 2000 GC exists in the organization. I would like to explain that the RPC over Http cannot use Windows 2000 GC.

     

    In addition, please also let me know whether the Exchange Server installed on Windows Server 2008 or Windows Server 2003 which have IPv6 components installed. Whether the GC is installed on the Exchange Server?

     

    For your reference:

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

     

    Mike

     

  • Wednesday, August 13, 2008 2:01 PM
     
     

    Hi Mike,

     

    We have no windows 2000 servers in our domain. the domain controller is server 2003 as is the exchange server. The domain controller is also the GC server. We are not using IPv6 on any of them. Ive pasted the event logs for the MSExchangeSA service this morning. The logs are the same throughout....no errors. Hopefully they show you something that i am missing.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9086
    Date:  8/13/2008
    Time:  9:45:48 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy worker thread (ID: 0xfd0) halved its internal free packet list.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9044
    Date:  8/13/2008
    Time:  9:45:17 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy received a close request on a circuit. The client or server has closed its connection with the NSPI Proxy. The circuit is being destroyed.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9052
    Date:  8/13/2008
    Time:  9:45:12 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy listener thread (ID: 0xeb4) listening on transport Rpc/HTTP created a new connection between a client and the Domain Controller on worker thread #0.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9142
    Date:  8/13/2008
    Time:  9:45:12 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy listener thread listening on transport Rpc/HTTP created a new connection between a client and Global Catalog DC.domain.local.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9141
    Date:  8/13/2008
    Time:  9:45:12 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy's list of targets has been updated.  Clients on transport Rpc/HTTP will be load balanced amongst the active servers in this list: DC.domain.local.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9141
    Date:  8/13/2008
    Time:  9:45:12 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy's list of targets has been updated.  Clients on transport Tcp/Ip will be load balanced amongst the active servers in this list: DC.domain.local.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9058
    Date:  8/13/2008
    Time:  9:45:12 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy successfully connected to the NSPI Service on server DC.domain.local at endpoint 1027 on RPC protocol sequence ncacn_http.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Event Type: Information
    Event Source: MSExchangeSA
    Event Category: NSPI Proxy
    Event ID: 9058
    Date:  8/13/2008
    Time:  9:45:12 AM
    User:  N/A
    Computer: EXCHANGESRV
    Description:
    NSPI Proxy successfully connected to the NSPI Service on server DC.domain.local at endpoint 1025 on RPC protocol sequence ncacn_ip_tcp.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Thanks for you help

    Colin

     

  • Thursday, October 02, 2008 1:58 PM
     
     

    Hi Colin, was this ever resolved. If not...

     

    Do I understand correctly that the certificate was issued to the common name of exchange.myextdomain.com, but the msstd setting points to exchange.extdom.com? What does the CertPrincipalName attribute point to? In Exchange Management Shell, enter the following and report back to us the value for the CertPrincipalName:

    Get-OutlookProvider EXPR | fl

     

    Thanks,

     

    Joe

     

  • Thursday, December 04, 2008 7:38 PM
     
     

    Hi Joe,

     

    So 2 months later, my exchange project has been re-established (after initially running into some user complaints that derailed it for a while). So i still sit in the exact same spot, everything works perfectly except RPC over HTTPS.

     

    I did what you suggested and surprisingly to me, the CertPrincipalName is blank (empty) as well as the Server heading.

     

    Also, the cert common name and the msstd name were the same, the extdom.com and myextdom.com was a typo.

     

    Any ideas

    Thanks

    Colin

     

  • Monday, December 08, 2008 3:26 PM
     
     Answered

    Hi Everyone.

     

    So i just got off the phone with MS tech support. 3 Hours later we had the fix. Here are the main points that resolved this issue.

     

    On our PDC & BDC:

    - We added the 'NSPI interface protocol sequences' registry key[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters] and rebooted

     

    On our exchange server:

    -       We added another registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

    Value Name: MaxWorkItems

    Data Type: REG_DWORD

    Value data: 8192 (decimal)

     

    -       Ran IISRESET and restarted the System Attendant service.

    -       Now, the username resolves while configuring a profile and Outlook connects on HTTPS without errors.

     

    This MaxWorkItems key seems to be the one that fixed the issue.

     

    Hope it helps for anyone else who may be having this issue.

    Thanks to everyone for their help.

     

    Colin

     

     

  • Thursday, January 29, 2009 4:31 PM
     
     

    Colin,

    You stated you installed this reg key on your PDC and BDC.  Am I to assume you were/ are running an NT4 domain, or do you have a PDC emulator service on an AD domain controller?

     

    I'm having strikingly similar issues with my Exch 07/sp1 environment, users are frequently prompted for credentials, RPC over HTTPS works okay, but still has issues and we have to use basic auth, no NTLM.

    Seems like any of the web services Address book / Free Busy info lookups can kick this endless credential loop off.

    Been running with this issue for over a year now and struggling through.

     

    Checked the PS command get-outlookproviders EXPR adn see our certprincipal name is blank too, also not sure we added a Subject alt name to our OWA cert for msstd:exchange.extdom.com

     

    Any reply would be greatly appreciated.

     

    Best regards,

    Brian

     

  • Thursday, January 29, 2009 5:01 PM
     
     

    one other question,

    You say "On our exchange server"

    Is your exchange server running all of the roles CAS/HT/Mailbox?  If no, which server did you put this registry change on?

     

    Thanks again,

    Brian

  • Thursday, January 29, 2009 5:33 PM
     
     

    Well, it appears with a little more digging today I may have found our issue.  This describes our environment exactly:

    Users May Be Intermittently Prompted for Credentials When Connecting to an Exchange 2007 Client Access Server from a Remote Location

    From Technet: http://technet.microsoft.com/en-us/library/dd361735.aspx 

    Topic Last Modified: 2008-11-12

    This topic provides information about how to work around an authentication issue that may occur when a Microsoft Exchange Server 2007 Client Access server is deployed in a reverse proxy environment.

    When you publish an Exchange 2007 Client Access server behind Microsoft Internet Security and Acceleration (ISA) Server 2006, users who use Microsoft Office Outlook 2007 to access their mailboxes from a remote location may be intermittently prompted for their credentials.

    Users experience this issue when Outlook loses connectivity with the Exchange server. This issue may occur in a high availability environment when a clustered Mailbox server fails over or when users have an unreliable Internet connection. This behavior occurs even if Outlook is configured to use Cached Exchange Mode.

    When Outlook loses connectivity with Exchange 2007, Outlook 2007 falls back to the connection methods that are configured in the Autodiscover settings for the user and for Outlook.

    To allow for a seamless user experience in an environment that uses Outlook Anywhere together with Exchange 2007 published behind ISA Server 2006, you must use Integrated authentication on the ISA Server Web listener.

  • Saturday, May 16, 2009 1:09 AM
     
     

    I was getting a similar error; Colin's "MaxWorkItems" registry modification resolved the issue.  Because my scenario was slightly different I'm posting details so that users with my problem can find this fix.

    In my scenario, I have added a new Exchange Server with the Client Access, Hub Transport and Mailbox roles installed.  Similar to Colin, I am unable to resolve the name of my new CAS via Outlook Anywhere.  I receive the error:

    "Outlook cannot log on. Verify you are connected to the network and you are using the proper server and mailbox name. The
    connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.  The name cannot be resolved. The action cannot be completed."

    What was interesting about my scenario, however, was that if I entered the name of my original CAS server then the name would resolve, correctly redirecting to my new server.  Also, my issue happened internally and externally; in other words, it wasn't specific to Outlook Anywhere (RPC over HTTP).  I point this out because, in my case, the Outlook Anywhere variable was a red herring. 

    I should also note that I did not add the NSPI registry modification; as Colin says, the MaxWorkItems is the key to fixing the issue. 

    I've added this to my company's Exchange migration knowledge base, but I'd sure like to know specifically what this key does and why this issue occurs in the first place.

  • Thursday, October 15, 2009 10:04 PM
     
     
    Hello,

    I am really amazed to see all the efforts deployed by the people here.
    However i dont understand how is it possible to reach such a deep level as for me these "services" should works without any issues.

    Microsoft is not a small company and exchange is now used by billions of users around the world.
    It's easy to sell Exchange 2007 saying that it's better and quicker and will give you access to your mail from anywhere. Sounds nice on the paper but behind we pull off our hairs.

    The most annoying for me is to see that a simple added key will solve this issue !?
    Sorry but what the ____ ?

    Poor Colin getting stuck 1 year, everyone might think he is not capable of .. and magic, you enter a key ?!


    Someone could explain what does this key ? how it bypass the problem ? is this key has been added to Sp2 or Exchange has been modified in Sp2 ?
    Why some people would need this key and some others will not ?


    I apologize but when it's not due to a lack of knowledges of end users, it is due to ? we dont know.. but a reg key solve it !
    So why do we spend hours reading IT books and passing certification to get stuck?

    There are nice things with 2007, but also things that should never dissapeared from 2003, hopefully we are saved with the last 2010 ..
  • For more information about how to configure authentication and Autodiscover for Outlook Anywhere, see the following topics:


    Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.

    Would you like to participate?