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
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 PMHoong, 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 PMModerator
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 0Any 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 1398Flags is 0
NumberOfParameters is 2Long val: 4
Long val: 1722
ProcessID is 3480
System Time is: 7/24/2008 13:18:29:368
Generating component is 13Status is 1722
Detection location is 1418
Flags is 0
NumberOfParameters is 0I 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 msThanks
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 60014. 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_PINGEDThanks 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
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 LocationFrom 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.
Cause 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.
For more information about how to configure authentication and Autodiscover for Outlook Anywhere, see the following topics:
Saturday, May 16, 2009 1:09 AMI 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 PMHello,
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 ..

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?
Products
Resources
Downloads
Evals
TechNet Support