locked
Outlook 2007 Cannot connect to Exchange 2003 via RPC over HTTP RRS feed

  • Question

  • I have configured an Exchange 2003 server to host RPC over http. My Outlook 2003 client can connect to it via https. When I attempt to connect using the same settings with Outlook 2007, it prompts over and over again for the username and password, never letting me in. I can't find any relevant info in the event log. The ssl cert is installed to the same place on both client machines.

    I have attempted this on 3 different client computers and 2 different exchange 2003 servers. Does anyone have any ideas?
    Friday, May 4, 2007 5:18 AM

All replies

  • Hi we have the same problem like you
    And Outook 2007 only connect once on ten times
    and it was working without trouble with outlook 2003

    Sitll looking for a solution


    Raf
    • Proposed as answer by outstream Thursday, December 15, 2011 1:14 PM
    Monday, May 7, 2007 7:21 AM
  • I just want to say that i too am having the same problem. What I've done, which worked for a very short while was,

     

    1. install outlook 2003 and configure it for RPC/HTTPS

    2. then do a upgrade install of outlook 2007. This works until I went in to check (w/ changes made) O2007's config.

     

    It seems that O2007 somehow messed up the config...

     

    M

    Monday, May 7, 2007 6:07 PM
  • Hi

    I know That trick Work
    But If I have to do this on 800 laptops, I can start  to  pray now

    Ra
    Thursday, May 10, 2007 1:40 PM
  • I just found this article and it worked for me.

     

    http://support.microsoft.com/kb/913843/en-us

    Tuesday, June 12, 2007 9:02 PM
  • Can you install O2003 if you are running Vista?
    Monday, July 9, 2007 9:56 PM
  • I'm having the same problem.  My OS is Vista Home Premium.  I've tried uninstalling Office 2007 and installing OL2003 but for some reason I still can't get RPC to work.  It works fine on my other XP Laptop with OL2003 and my desktop owith th e same.  It just keeps prompting me for a username/password but it never connects.

     

    I've checked my firewall - I'm running McAffee Security Center and Outlook 2003 has full access.  I also have windows defender and windows firewall turned off.

     

    Any thoughts?
    Tuesday, July 10, 2007 11:03 AM
  • Same problem here Smile

     

    (French guy so excuse my english !)

     

    My laptop with outlook 2k3 (XP_SP2) works fine and can connect with rpc over https, and new laptop (XP_SP2) with Outlook 2k7 can't connect with rpc over https.

     

    I've a single server configuration, and i create my certificate (so it's not come from an approuval source)

     

    When I check log on my IIS server i can find trace of my connection tentative (on port 6001,6002,6004 but no continuation on port 593 as usual)

     

    Another thing, i can't try this KB : http://support.microsoft.com/kb/913843/en-us

    because i don't have the last Folder : 'RPC' under outlook...

    someone in my case for this point ?

     

    Any idea ?

     

     

     

    Wednesday, July 11, 2007 3:10 PM
  • Anyone have any more joy with this?

     

    I have tried everything I know and still cannot get it to work, its very frustrating, is anyone from Microsoft able to help?

     

    Frustrated User

    Friday, July 13, 2007 2:42 PM
  • Hi All,

     

    Actually it works with me only at my office network, but when I switch public network I get this frustrating error. Just now I added the DefConnectOpts to the registry but still didn’t work?

    This requires a serious attention……

     

    ZashNet
    Sunday, July 15, 2007 5:06 AM
  • I am getting a similar error when connecting an Outlook 2007 Client to Exchange 2007 Server.

    A username/password box continually comes up asking for a username and password to connect to Exchange, and it will not accept anything I put in.. strangely, I can hit Escape and still send/receive emails.. until it pops up again.

    Sunday, July 15, 2007 12:13 PM
  • Well i create RPC key in registry and add  DefConnectOpts value, it's working now...

     

    For information i use Exchange 2k3, one server and i use my certificate.

     

    I reinstall certificate on the laptop before try to add the key in registry.

    Monday, July 16, 2007 12:53 PM
  • Same issue for me!

     

    Outlook 2003 clients can connect to my Exchange 2003 server via RPC/HTTPS.

     

    New Vista laptops with office 2007 (I didn't recomend them!) won't connect at all via RPC/HTTPS.

     

    I looked at hte article http://support.microsoft.com/default.aspx/kb/913843/en-us

     

    I do happen to have a gateway IP, and can esolve the external name of the mail server internally via a DNS record I have added, so I know Outlook is talking to the server (plus the Security Log is filling up with errors).

     

    I had to add the RPC reg key and DWORD value, but these made no difference.

     

    What next Microsoft? Some step by step instructions would be nice.

    Wednesday, July 25, 2007 12:44 AM
  • I'm having the same problem here.  I have a new Vista business with Outlook 2003.  This is frustrating.  Worse,  the OWA does not work with IE 7.0 and Vista (when you click 'reply' to emails).  We need to patch the Exchange server to make it work.  Basically I have nothing that works for email checking Sad

     

    Anyone knows how to fix the RPC over HTTP in Outlook 2003 and Vista Business please?

    Sunday, August 5, 2007 3:39 AM
  • I have the same problem with Outlook 2007, outlook 2003 works fine i've tried these following KB. MS any help?

     

    http://support.microsoft.com/default.aspx/kb/913843/en-us

     

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

    Tuesday, August 7, 2007 2:24 PM
  •  

    After much trouble, we got it to work. Don't know why, but here's what we did.

     

    Main point: VPN into SBS 2003 as Admin got it working, even without tunneling in later.

     

    Setup

    • SBS 2003, sp1
    • Vista Home Premium
    • Office 2007 Pro

    What we did (skipping details)

    • Local (Vista) account was setup as Admin, later demoted
    • Installed certificate
    • Setup profile as required
    • Connect to SBS 2003 as Administrator (didn't work with user account that we wanted to access).
    • Start Outlook and login as the user whose email we are configuring (not the Admin account).
    • Initial setup (name, initials, etc), then data synchronized.
    • Close Outlook, and log off the Vista account
    • Demote the Vista user from Admin to a standard type account.
    • Reboot so we know we have a clean start
    • Logon to the account whose email we are setting up
    • Start Outlook and logon. It works.

    We've done this for two accounts on the same Vista box. So far so good.

    No idea why it works. My IT consultant came up with this idea after failing with other things.

     

    I hope possibly it may help you.

     

    David

    Sunday, September 2, 2007 12:03 AM
  • I called MS Support in the end and discovered a fix (there may be a number of fixes that work, but here's mine...

     

     

    We were using the NetBIOS domain name in the credentials , ie

    DOMAIN\username

     

     

    When we changed the credentials to

    internal FQD name\username

     

    It started to work.

     

    The documentation says that NetBIOS name will work. That's what we've always used with Outlook 2003. It doesn't work with 2007. The MS guy acknowledged this as an issue andwas kind enough to give us te call for 'free'

     

    I can only hope it works for everyone else!

     

    Good luck

     

    Robert

     

    Monday, September 3, 2007 1:57 AM
  • Anyone else figure something out with this issue?  I have been beating my head against the wall all day trying to figure it out.  None of the prescribed fixes have worked.  thanks!

    -jrod
    Tuesday, September 18, 2007 11:39 PM
  • JRod,

    When I started this topic months ago, the problem I was having really had nothing to do with Outlook 07 connecting to Exchange 03, as I learned. I've had much experience setting up private certificates, but whatever reason, this time I just couldn't get it to work. I paid the $20 for a Godaddy cert, and since that day I have vowed to never try and use a private cert again. The Godaddy certs are so cheap, and they work every single time.

    If you're still having trouble with this, reply to this post with the things you've tried and I'll try and help you.


    Jess
    Wednesday, September 19, 2007 5:55 AM
  • My main issue lies in Outlook 2007 trying to connect to Exchange 2003 SP2 via RPC over HTTPS (referred to as Outlook Anywhere in Outlook 2007).

    Using the exact same settings as with an Outlook 2003 client (which works) I get continually prompted for a username/password like it cannot authenticate.  It will finally error out and say Outlook isn’t available.


    I have tried this fix: http://support.microsoft.com/default.aspx/kb/913843/en-us and no dice.

     

    I have tried using NTLM auth instead of Basic, I have tried turning off Encryption between Outlook and Exchange.


    I have a GoDaddy cert on the Exchange server that its trying to connect to.  I know its setup right because Outlook 2003 doesnt have any issue connecting with it.

    ideas?


    Wednesday, September 19, 2007 5:14 PM
  • Okay Jarrod, here's what I would do:

    Undo the reg change you did in the registry regarding the DefConnectOpts DWord Value. As far as I can tell, that is only for use on computers that don't have a default TCP/IP gateway, and surely yours does.

    Set the Encryption settings back to default in Outlook.

    Be sure and set your authentication method to basic, I've seen NTLM cause problems in the past.

    Test your Godaddy Cert on the computer. Using IE, go to https://"whatever you address is".com/exchange. Make sure NO security errors come up, and you can login with the username.

    And finally, when you open Outlook and it asks for the username and password, I've had the best luck with the following convention:

    DOMAINNAME\USERNAME
    PASSWORD

    So if my domain is SCC.LOCAL use: SCC\Jess


    All the things I'm suggesting are on the client side because you said you have other Outlook 2003 clients that successfully connect right? Let me know what happens.

    Thursday, September 20, 2007 3:19 PM
  • Here is my issue along the same lines.

    Brand new Dell laptop with XP Pro OS and Office 2007.

    Server is setup and working wonderfully with other Outlook 2003 clients.

    I have one other new laptop with XP Pro OS and Office 07 that for some reason the RPC over HTTP is working.

    The one I am having a problem with, takes the username and password. However, it just does not connect to the Exchange server.

    It works fine once on the network, but not once I am off the network.

     

    Any ideas??

     

    Thank you in advance.

     

    Wednesday, September 26, 2007 6:17 PM
  • This is an absolute disgrace. I've tried everything, and can't get this to work. And believe me, I know my stuff.

     

    You know what really sucks about this: I'm a Microsoft Partner and I always try to play "on the team," and promote Microsoft products to my clients. It's so disappointing when this kind of BASIC STUFF happens. Worse yet, it happens, and nothing is done about it, and there is no acknowledgement of any kind.

     

    Why is there no acknowledgement? Why is there no fix? Why are people having to fiddle around with these advanced settings, anyway? This is Microsoft's PREMIER email product, connecting to THEIR proprietary PREMIER email server product. How do I explain such serious shortcomings to my clients, or to potential new clients?

     

    Why are experienced IT guys and gals having to spend their entire days on this stuff?

     

    GET IT TOGETHER MICROSOFT. I want to see a hotfix posted TODAY, Wednesday, September 26th 2007, by 6PM Pacific Time. Do it.

     

    Wednesday, September 26, 2007 9:47 PM
  • We are also a partner and have lost several hosting clients due to this...

     

    I have know idea why Microsoft has left this so long

    Wednesday, September 26, 2007 10:36 PM
  • I got my settings to work.  I configured Outlook to use NTLM, cached Exchange mode (Which is default) and selected to use Outlook Anywhere.  That did it for me.

    Thursday, October 4, 2007 1:20 AM
  • Thursday, October 4, 2007 6:32 PM
  • Tried that (last week). Doesn't work. Nothing works.

    Thursday, October 4, 2007 8:14 PM
  •  qmacker wrote:

    Tried that (last week). Doesn't work. Nothing works.

     

    I posted this on Sunday, how could you have tried it last week? There are a couple of added steps towards the bottom.  Can you connect with XP computers?  What do you get with the RPCPIng utility (http://support.microsoft.com/kb/831051)?

    Thursday, October 4, 2007 8:57 PM
  • I tried the DefConnectOpts (saw it in another post). No dice. Like you, I didn't have the RPC key, so I created it myself. I tried rebooting, creating the profile again, etc. etc. I've also tried the following:

     

    - the Server2003NegotiateDisable key (on/off, doesn't matter)

    - DOMAIN\username

    - FQD name\username

    - username@FQDname

    - deleting profiles

    - NTLM on/off

    - BASIC on/off

     

    I've also tried this LABORIOUS "fix" (which doesn't work either) using the Setspn tool:

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

     

    To answer your other questions:

     

    Yes, it works fine with XP SP2 machines, running Outlook 2003 using RPC over HTTP. We've also got "real" certificates.

     

    The one thing I haven't tried is the RPCPIng utility. I'll give that a shot, and get back to you all.

     

    THIS IS DRIVING ME CRAZY!

     

    WHERE IS MICROSOFT?!!!!

    • Proposed as answer by Carol F Thursday, October 29, 2009 12:25 AM
    Thursday, October 4, 2007 9:39 PM
  • Same problem here none of the above mentioned fixes work. Environment is Windows 2k3 SP2, Exchange 2k3 Sp2, Windows XP SP2, Outlook 2007.

    RPC over https works flawlessly witn Outlook 2k3 clients. There is not rational explanation to all these various fixes that are being thrown out here. I have a gateway, I don't have an RPC issue with any of my Outlook 2003 clients. So clearly there is something that has changed and we need to get this resolved.

    Can someone from the Microsoft Exchange team chime in here? Obviously none of these intended to be helpful suggestions are working.



     qmacker wrote:

    I tried the DefConnectOpts (saw it in another post). No dice. Like you, I didn't have the RPC key, so I created it myself. I tried rebooting, creating the profile again, etc. etc. I've also tried the following:

     

    - the Server2003NegotiateDisable key (on/off, doesn't matter)

    - DOMAIN\username

    - FQD name\username

    - username@FQDname

    - deleting profiles

    - NTLM on/off

    - BASIC on/off

     

    I've also tried this LABORIOUS "fix" (which doesn't work either) using the Setspn tool:

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

     

    To answer your other questions:

     

    Yes, it works fine with XP SP2 machines, running Outlook 2003 using RPC over HTTP. We've also got "real" certificates.

     

    The one thing I haven't tried is the RPCPIng utility. I'll give that a shot, and get back to you all.

     

    THIS IS DRIVING ME CRAZY!

     

    WHERE IS MICROSOFT?!!!!

    Tuesday, October 9, 2007 11:50 PM
  • I don't mean to belabor this fix, but I had the exact same setup on multiple clients.  I had to contact microsoft exchange support and pay for support on this.  Again, mulitple domains, multiple servers, multiple clients.  Everytime that I have done the following, it has worked.

    1. Create the RPC key in HKEY_Current_User accouding to http://support.microsoft.com/default.aspx/kb/913843/en-us.
    2. Reboot and log into that same user profile.  This fix has to be done in each user profile.  (You cannot log in as administrator and create the registry key, then log in as joebob and have it work.)
    3. Go to control panel, mail and delete the current user profile (understand the implications of this before doing it).
    4. Still in the mail control panel, create a new outlook profile setting up the Outlook Anywhere settings.
    5. Start outlook and test the RPC over HTTP settings

    Setup:

    Exchange 2003 SP2

    Windows Server 2003 SP2

    Vista Business

    Outlook 2007

     

    Other Notes:

    When Installing Outlook 2003 on Vista, RPC over HTTPs worked.

    After upgrading Outlook 2003 to Outlook 2007, the settings still work.

     

    Installing Outlook 2007 on a fresh install of Vista, one must perform the fix outlined above for RPC over HTTPs to work.

     

    This procedure has been done on computers connected to the domain and off-domain.  Vista Business, Ultimate and Home Premium (off-domain)

     

    This also assumes that the CA on the domain is installed as a trusted root authority.  Even with the certificate installed incorrectly, this still worked.  It just threw up an annoying error to the user, but that user still connected.

    Saturday, October 13, 2007 5:09 PM
  • Hi everyone!
    Can someone confirm this last tip works? I dont dare test this on my customer, if i does'nt work... their angry enough...
    I have 4 brand new Hp's with XP and Office 2007 pre-installed and i can't connect to Exchange 2003 over http.
    I Have tried every fix on this thread but no-go and i'm pretty sure i've tried this last stuff also..maybe not in this exact order tho...

    Cheers!
    Ajje

    Monday, October 15, 2007 7:02 AM
  • This is specifically to correct issues with Vista Computers, Outlook 2007, and Exchange 2003.  XP computers do not have the same issue that Vista machines do.

     

    On your client computers, what happens when you use the RPCPIng utility (http://support.microsoft.com/kb/831051) outside of the office?  Do you get a response or an error?  Have you connected before with outlook 2003 clients to exchange while outside the office?

    Monday, October 15, 2007 4:41 PM
  • Still doesn't work, I'm sorry - and very angry - to say.

     

    Monday, October 15, 2007 9:48 PM
  • None of these suggested fixes work on an XP workstation with Outlook 2007 when connecting to Exchange 2k3 with RPC over HTTPS.

    We are still waiting for Microsoft to chime in on which one of their updates broke RPC for XP/Office2k7/Ex2k3 or provide a workaround other than those listed here.

    Tuesday, October 16, 2007 12:52 AM
  • Gotchaa is right, I have tried every one of these fixes (and different variations thereof) and nothing will work on an XP Outlook 2K7 machine and Exchange 2003 for RPC over HTTPS.  I am actually having to look at upgrading my infrastructure to Exchange 2007 because of this issue.  Unacceptable isnt even an appropriate word for it anymore.

     

    Tuesday, October 16, 2007 3:27 AM
  • I am also having problems with this.

     

    XP machines

    Exch2003 SP2 on Win 2003

     

    Outlook 2003 works fine. Outlook 2007 works within our environment for both domain and non domain machines, but cannot connect via RPC/HTTPS

     

    Still not sure if this is an autodiscover problem or outllook 2k7 not useing the required protocol.

     

    Tuesday, October 16, 2007 7:45 AM
  • Got it- IE7 in Vista wasn't installing it in the right location it needed to
    be under Trusted Root Certificates or Enterprise - not sure which yet.

    I tried both and it works

    see the link

    http://www.issociate.de/board/post/408792/IIS_Certificate_for_Exchange_2003_-_not_working_for_Vista?.html

     Ran
    Monday, October 29, 2007 9:42 AM
  • Not sure what your fix is? The problem occurs with well known trusted CA's such as Verisign and Thawte. Sounds like you had a different issue.
    Tuesday, October 30, 2007 8:42 AM
  • I have the same issue now.
    But before 1 month outlook 2003 and 2007 both working and I use the servername xxx.domain.local
    but after I change the CA, outlook 2003 only working with servername xxx,  if I put in xxx.domain.local it no working.
    For the outlook 2007  after I setup first time it do run https for a a shart time 3s,then It go dead.
    still waiting for the solution!
    Thursday, November 1, 2007 5:48 PM
  • I know this is not a fix and is not the ideal way to use RPC/HTTP for exchange but change the authentication method to basic and it will likely work.  There is some problems with vista and Outlook 2007 with exchange 2003 but no one seems to know what they are or how to really fix it.  Hope this helps.

     

    Friday, November 2, 2007 8:00 PM
  • While I appreciate the helpful comments, these are not fixes. Most using SSL Certs from Trusted Root CA's already have authentication set to basic.

    What we really need is for Microsoft to step up and provide an explanation and fix for this. Do they even monitor these forums,  or is this an unresolved bug?
    Friday, November 2, 2007 9:27 PM
  • Agreed.  I have been having this problem for sometime and not gotten a solid workaround let alone a fix.  Sometimes the adding of the reg key fixes it others the entire pc needs to be rebooted, and then sometimes it seems to work but everytime they open their outlook it prompts them for a password once.

    None of these 'workarounds' are actual fixes.  Can we have a hotfix or something MS.  They want us to move to Vista and Outlook 2007 etc.. but then all these unresolved issues exist.......
    Monday, November 5, 2007 10:49 PM
  •  

    The issue I had with Exchange 03, outlook 07 and XP PRO, with off domain computers was that it was putting the locally logged on user into the mail settings. It was completely ignoring the pop up box setting when you tried to connect to the exchange. It was really bad if say you are logged in as Administrator on your local machine. The work around I came up with was to login to the local machine, got to the control panel go to Mail, go to email accounts, view change existing, and make sure your correct username is in the exchange profile. After I verified these settings everything work flawless for me.

    Friday, November 16, 2007 3:53 PM
  • This is not the issue that many of us are experiencing here, nor is it the workaround. Please don't confuse the issue here with your corner case configuration error.

    We still do not have an explanation or a fix to RPC over HTTPS for Outlook 2007 users connecting to Exchange 2k3 servers. I recommend everyone visit the purported KB article and provide feedback that it does not work and link to this thread.
    Saturday, November 17, 2007 12:39 AM
  • After reviewing this thread I'd like to make the following suggestions: (If you've performed these steps you feel to the best of your ability and you still can not connect, I would advise calling us in Product Support so we can help investigate)

     

    1) Create a new profile in Outlook and choose to configure your settings manually.

     

    2) Verify 927612 You are repeatedly prompted to enter your credentials when you try to connect to an Exchange 2003 mailbox by using Outlook 2007
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;927612

     

    3) Verify 913843 Error messages when you try to connect Outlook 2007 to Exchange Server: "The action cannot be completed" or "Your Microsoft Exchange Server is unavailable" or "Cannot start Microsoft Office Outlook"
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;913843

    If you call PSS please create a test user account that you know can connect to the Exchange server and send/receive mail with. This does not have to be verified via rpc/http but standard rpc/tcp or OWA connection test would be fine.

     

    Hope this helps,

    Brad

    Saturday, November 17, 2007 2:28 PM
  •  Brad Wilson [MS] wrote:

    After reviewing this thread I'd like to make the following suggestions: (If you've performed these steps you feel to the best of your ability and you still can not connect, I would advise calling us in Product Support so we can help investigate)

     

    1) Create a new profile in Outlook and choose to configure your settings manually.

     

    2) Verify 927612 You are repeatedly prompted to enter your credentials when you try to connect to an Exchange 2003 mailbox by using Outlook 2007
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;927612

     

    3) Verify 913843 Error messages when you try to connect Outlook 2007 to Exchange Server: "The action cannot be completed" or "Your Microsoft Exchange Server is unavailable" or "Cannot start Microsoft Office Outlook"
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;913843

    If you call PSS please create a test user account that you know can connect to the Exchange server and send/receive mail with. This does not have to be verified via rpc/http but standard rpc/tcp or OWA connection test would be fine.

     

    Hope this helps,

    Brad



    Brad,

    I did not need to create a new profile, however article 927612 and 913843 solved the problem. In particular changing the existing profile to use NTLM authentication, and leaving the Exchange Proxy settings for "Outlook Anywhere" to use Basic Authentication was what worked as well as the GC settings. I followed both steps of these KBs and the problem was resolved. While I am glad the workaround works, the root cause is still a mystery as the Exchange server I am working with was already a global catalog server. Regardless I followed the steps for re-registering the SPN as well as the profile settings and registry key setting on the client and all is well. It would be nice if Microsoft would provide a better explanation of the cause as well as details as to why and in what circumstances the "workaround" introduces risk as indiciated:

    "Warning This workaround may make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk."



    Saturday, November 17, 2007 7:28 PM
  •  

    From my understanding from reading some of the history on the Knowledge Base article it seemed Outlook 2007 had some problems when retrieving SPNs to allow Kerberos authentication and would not allow failing back to NTLM. The registry entry helps alleviate that.

     

    The section of the Knowledge Base article you mention in the Warning I feel will be changed before long.

     

    I'm glad everything is working now for you.

     

    -Brad

    Wednesday, November 21, 2007 6:29 PM
  • STILL doesn't work (all these months later).

    I've tried installing Vista from scratch on a virtual machine, then I installed Office 2007 Enterprise on that (virtual) machine. I did not join the virtual machine to the domain, and Outlook connected fine (using RPC over HTTPS).

    From a few other threads I've read, there seems to be circumstantial evidence pointing to machines with an upgrade install of Office 2007 (from a pre-installed trial retail on the box) not being able to connect. One poster did suggest wiping the entire machine and reinstalling with a clean version of Vista and Office 2007 Enterprise. Like I've said before, that's a pretty extreme step. This is Microsoft's own premier office-email product, connecting to their own premier email server system.

    It should not require any "tweaking" whatsoever to get it working. This is supposed to be serious business-oriented software, for heaven's sake.
    Wednesday, January 9, 2008 2:07 AM
  • HI Brad,

     

    i have an issue here, i am using Win XP Prof and Outlook 2007 while exchange are 2003.

    i have successful connect to exchange and successful send and received. But whenever we are trying to compose NEW message email and click on *TO* the outlook will hang there.

     

    After checking the microsoft exchage status by CTRL + Right Click. We show that all are establish except the TYPE Directory are keep showing *Connecting*. Can i know what should i do now?

     

    But when we are connect internally it work fine.then when the user work at home and trying to use RPC over https its will hang like what i mention just now.

     

    Look forward for your response. appreciated it.

     

    Thanks

     

    Wednesday, January 9, 2008 3:17 AM
  • HI Brad,

     

    i have an issue here, i am using Win XP Prof and Outlook 2007 while exchange are 2003.

    i have successful connect to exchange and successful send and received. But whenever we are trying to compose NEW message email and click on *TO* the outlook will hang there.

     

    After checking the microsoft exchage status by CTRL + Right Click. It show that all are establish except the TYPE Directory are keep showing *Connecting*. Can i know what should i do now?

     

    But when we are connect internally it work fine.then when the user work at home and trying to use RPC over https its will hang like what i mention just now.

     

    Look forward for your response. appreciated it.

     

    Thanks

     

    Wednesday, January 9, 2008 3:18 AM
  • Forgive me if this issue was already fixed in here but, thought I'd let you know if any of you get this message below when you try to open Outlook 2007 via RPC over HTTP and using Vista.

    "there is a problem with the proxy server's
    security certificate. The security certificate is not from a trusted
    certifying authority. Outlook is unable to connect to the proxy server
    mail.mydomain.com (error code 8)."

    Follow the link below and you it should solve your problem. Thanks guys, you provided a great source of info for me to work with. Good luck!

    http://support.microsoft.com/kb/923575
    Friday, January 18, 2008 2:45 AM
  • WOW-----Simple and Effective.  I have been using OWA for six months because I could not fix this!  Thank You!

     

    Jess Buller, your my Hero!

     

    From JESS

     

    Okay Jarrod, here's what I would do:

    Undo the reg change you did in the registry regarding the DefConnectOpts DWord Value. As far as I can tell, that is only for use on computers that don't have a default TCP/IP gateway, and surely yours does.

    Set the Encryption settings back to default in Outlook.

    Be sure and set your authentication method to basic, I've seen NTLM cause problems in the past.

    Test your Godaddy Cert on the computer. Using IE, go to https://"whatever you address is".com/exchange. Make sure NO security errors come up, and you can login with the username.

    And finally, when you open Outlook and it asks for the username and password, I've had the best luck with the following convention:

    DOMAINNAME\USERNAME
    PASSWORD

    So if my domain is SCC.LOCAL use: SCC\Jess


    All the things I'm suggesting are on the client side because you said you have other Outlook 2003 clients that successfully connect right? Let me know what happens.

    Saturday, January 19, 2008 6:04 PM
  • Hi, 

     

    I have 140 users running XP pro SP2 with Office 2000; our server is running Exchange 2003.  We are in the process of upgrading all users to Office 2007.  After the upgrade, half of the users get the following error when trying to open Outlook:  The Microsoft Exchange server is unavailable.   Oddly enough, other users have no problem connecting to Exchange after the upgrade and the client settings/configs are identical!

     

    MS has been totally unhelpful!  These threads seems to be focused on machines running Vista.  Has anyone with XP machines had a similar problem and does the workaround in KB 913843 article work for XP?  Any feedback or other ideas would be appreciated!

     

    Thx!  LeighR
    Monday, January 21, 2008 3:14 PM
  • LeighR,

    I have several XP Sp2 machines with the exact problem.  1/2 work just fine and the other have the same issues you are having.  No, KB 913843 did not help me (and neither did installing SP1 for Office 07). 

    To add insult to injury for me, I don't even run RPC over HTTP!!

    You are not alone!!

    MS.. We need your help!!
    Tuesday, February 5, 2008 12:15 AM
  •  

    The same problem here.....My solution was to put the domain name and the user name in the user are of the logon.  USER: domain_name/username.  It solved the problem for me.  Good luck

     

    Friday, February 8, 2008 2:39 PM


  • Non of the fixes worked for me.. Funny how office 2003 has no issues and 2007 doesn't work at all.

    What is the product support phone number?
    Tuesday, March 4, 2008 7:38 PM
  • yo.. well i have tested few months ago..its not stable to use ms office 2007 to connected to exchange 2003. it sometime will connected successful and sometime cant! so if i am not mistaken that ms office 2007 is especially built for exchange 2007. so change to outlook 2003 and its work perfect!!

    Tuesday, March 4, 2008 10:43 PM
  • Adrenaline_X,
    I opted to go thru email support to use my one free Office 2007 tech support call and to provide them a link to this thread so they had some backround before contacting me.  Girish from MS then contacted me 2 weeks later (
    425-635-3106 Extn: 59201.)

    As I expected, as soon as the words "exchange" came out of my mouth, he said he didnt have any training with Exchange and this was no longer a free support issue.  He then transferred me (25 minutes later) to the Exchange department's... cashier (for lack of a better word), who would not transfer me to an exchange specialist without charging me the $250 for a support call.  I had to decline, but it was obvious that they were not listening to my explanation and had no interest in looking at this thread or helping me sort out this issue (without taking my money of course).

    Good luck.


    Wednesday, March 5, 2008 6:51 PM
  • It's amazing to me that here we are, almost a year later, and this problem is no closer to being resolved. I can't believe i posted to this thread overa year ago.

     

    Quick question everyone: By any chance, of those of us having this problem, are any of you running Office 2007 on machines that already had a "trial" version of Office 2007 pre-installed? This is true in my case, and I did an upgrade install of Office 2007 Enterprise over the trial version. I activated it, and it works fine (apart from this).

     

    I have another "fresh" machine that just arrived with another Office Trial on it. It'll be a good test to see if the Office 2007 Enterprise I installed over that can connect to Exchange. I'll keep you all posted - I think this thread will be alive for a while longer!

     

    (As an aside - I'm not an anti-corporate type, but I do have a theory that very large corporations are kind of like governments, and become so spread out and bureaucratic that it is impossible for them to "mend" their problems, even if they mean well. I think the senior folks at MS/Exchange might be horrified if they ever saw this thread, but they unfortunately never will. And that of course, is their poor project management. Just my 2c).

     

    Wednesday, March 5, 2008 7:53 PM
  • My Outlook 2007 was obtained through an upgrade to 2007 Office Ultimate.  I was already running Vista with the full Works package and the 2007 Office Student Teacher Edition.  The work email server I connect to (still works fine through the web) is Exchange Server 2003.  My employer only allows an elite few to have access to VPN - it's a long story; I bought 07 office specifically because outlook 07 would allow me to sync remotely utilizing rpc over http. 

     

    I have tried all the fixes suggested in the KB. I have tried working with my in-house IT guys, but they feel no real obligation to assist me since my system/software was not a corporate purchase - they have not moved into Vista or 07 yet. 

     

    Despite no longer being an IT professional, I used to be one, and I consider myself quite savvy when it comes to solving these sorts of problems.  I have spent days (spread over the months since December) trying to get this to work.  I am not willing to spend money to contact tech support to fix something that is supposed to be a basic function of the program I purchased. 

     

    qmacker may not always be the most tactful in his statements, but I wholly identify with his frustration.  I have resorted to my PDA/phone being the central sync point for all this data.  One would think that the more advanced system on my notebook would be able to do better than my phone with Windows Mobile 6.0. 

    Friday, March 21, 2008 9:21 PM
  • Having a similar problem with RPC/OA here also. I got it working on a brand new VM with Outlook 07 and a few other machines, but I cannot get it working on mine. This is the error I get:

    Cannot open your default e-mail folders. The file <folderpath>outlooknew.ost cannot be accessed. You must connect to Microsoft Exchange with the current profile before you can synchronize your folders with your offline folder file

    I'm tearing my hair out on this. The account name can resolve against the Ex server, I've created new OST files, used old OST files, created new profiles, disabled offline files, tried the RPC DWORD reg fix, switched between Basic and NTLM, and have a valid cert on the server, but none of that is helping.

     

    Damn MS

    Monday, March 24, 2008 5:29 PM
  • Only 5 weeks and a few days to go, and it'll be the one year anniversary of this thread.

     

    We should have a party!

     

    Monday, March 24, 2008 6:35 PM
  • Okay, I may have found a work around:
    In Account Settings, and Exchange proxy Settings, I clicked the box for "On fast networks, connect using HTTP first, then TCPI/IP", and now it's connecting fine! ....only problem is that now it prompts for a password every time, even when users are in the office. Anyone have any more clues?
    Friday, March 28, 2008 2:58 PM
  • Those of us having the ongoing problem have tried that (and many other things), Cosmin1086.

    Thanks all the same, though.

    Respectfully,

    qmacker.

    Friday, March 28, 2008 11:38 PM
  • I am receiving the message when I click check nameafter all settings are in place "The action cannot be completed. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action." Does anyone have a fix. Microsoft please step up, this is ridiculus!!!!!!!!!!!!!!!!!!

    Saturday, March 29, 2008 4:05 PM
  • Try this at the outlook client end.

     

    Changes to be done at the Outlook client
     
    1. Click Start, click Run, type regedit in the Open box, and then click OK.
    2. Locate and then click the following subkey:
             HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC
    3. On the Edit menu, point to New, and then click DWORD Value.
    4. Type DefConnectOpts, and then press ENTER.
    5. Right-click DefConnectOpts, and then click Modify.
    6. In the Value data box, type 0, and then click OK.
    7. Exit Registry Editor.

    Please let us know the result support@velaninfo.com
    Monday, March 31, 2008 7:05 AM
  • Do you have imported an frontend exchange server certificate ? Or other thing may help - Windows Vista utilizes new technology - TCP scalable networking and once your NB isn't part of a domain but just workroup, then scalable networking may be a big trouble. One solution may be switch off every extended option on network card settings which contain word "flood".

     

    So:

    - Be sure you have imported proxy exchage server certificate - if you haven't one you must ask admin of exch. server

    - Try disable every setting on network card which contain word "flood"

     

    Once you get an logon dialog window in Outlook you're winner. Just enter domain/login in name field and password and go connect Surprise)

     

    Choose Basic password option in Outlook RPC Proxy settings dialog box

     

    Sorry for my bad english...

     

    I wish you luck...

     

     

     

    Wednesday, April 2, 2008 4:28 PM
  • Hi.

    I have the exact same problems with Outlook 2007 connecting to Exchange 2003. I added the registry setting in this article: http://support.microsoft.com/kb/913843/en-us.

    Everything is working great after this.

     

    Regards, Kolbjørn

     

    Wednesday, May 28, 2008 8:31 PM
  • If I hear about this DefConnectOpts regkey one more time, I think I'm gonna shoot myself.
    Thursday, May 29, 2008 8:41 AM
  •  

    I was able to resolve this by checking

     

    "Always prompt for logon credentials"

     

    and setting "Logon network security:" to

    "Password Authentication (NTLM)" from negotiate.

     

    Under the Exchange Account settings, Security tab.

    Thursday, June 26, 2008 10:42 PM
  • There have been many fixes here and so it seems that there are many issues.  In my case, the PC was XP Pro with Outlook 2007.  NONE of the previous fixes worked.  My Outlook 2003 Clients did work.

     

    After much research, I went back to the drawing board and went over the suggested RPC/HTTPs settings for Exchange found here:

    http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

     

    All my settings were correct EXCEPT for one part: configuring the ports for RPC/HTTPs.  I used the RPCNoFrontend tool suggested and found here: http://www.petri.co.il/software/rpcnofrontend.zip to set the ports and BINGO!  I had no more problems after that. 

     

    I have no idea why it worked in Outlook 2003 and not Outlook 2007 but I've seen stranger things.  Hope this helps.  Good luck all.

     

    Monday, June 30, 2008 8:19 PM
  • I can confirm that this doesn't work for me.

     

    I'm pretty convinced this is a client-side problem. I have plenty of other Outlook 2007 clients that can connect.

     

    My highest suspect is "Trial" copies of Office 2007 that have be upgrade-installed to full versions. I promised this a while ago, but I'll be checking out another upgrade-install in a day or two. I'll try and post back.

     

    I have had no issues with first-time clean installs of Office/Outlook 2007 clients connecting.

     

    Saturday, July 12, 2008 2:01 AM
  • Hi everyone,

     

    I am also facing a similar problem. Here is the description of my environment:

    - Windows Server 2003 R2 Standard Ed. with SP2

    - Exchange Server 2003 with SP2

    - DC, GC, Exchange - all roles on a single server.

    Exchange server is using a self-signed certificate which is trusted by client machines that are accessing it via RPC over HTTPS functionality.

     

    My clients are Windows XP SP2 machines with Outlook 2007 installed. I was able to set up RPC over HTTPS, but it didn't work from time to time. I couldn't find any pattern in the behaviour. One day it worked, second day it didn't.

     

    I did manual configuration of ports used by RPC Proxy server.

    My Exchange server has different internal FQDN from external FQDN which is used to access it from internet.

     

    After reviewing article on: http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm, I used RPCNoFrontEnd utility (descibed in the article) to set up ports on the Exchange server, this time to include both internal and external FQDN in the ValidPorts registry entry.

     

    Example:

    Netbios name: server

    Internal FQDN: server.domain.local

    External FQDN: mail.domain.com

    Users have the following e-mail addresses: @domain.com

     

    After that, I have added "domain.com" as an additional UPN suffix to AD Domain and reconfigured Outlook clients to connect to server via RPC over HTTPS using username@domain.com as username.

     

    Since then, RPC over HTTPS in Outlook 2007 is wotking fine. Hopefully, it will stay that way. :-)

     

    Let me just add that I have also used Microsoft Update to update all of the MS Office components to the latest level.

     

    Maybe this will help someone.

     

    Best regards,

    Vedran Matica

    Monday, July 14, 2008 12:03 PM
  • I am having a similar problem with SBS (small business server with 5 cals) 2003 connecting with Outlook 2007 over a VPN connection. The VPN connects and I can view shared folders etc. but outlook always says it can't find the server. Any similar fixes please? My laptop synchronises over a wireless connection in the office.

     

    Cheers

     

    Bob

     

    Monday, July 14, 2008 2:05 PM
  • We are using Windows Vista Ultimate, Outlook 2007, RPC over HTTP, Exchange Server 2003, Windows Server 2003 Standard Edition SP1. Ptolemy's solution worked for me. 

    Notes:
    The Microsoft registry tweak at http://support.microsoft.com/default.aspx/kb/913843/en-us does not specifically mention that if the key
    HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC does not exist the RPC key should be created 1st before the DWORD is added.

    Thank you to Ptolemy




    Friday, July 18, 2008 3:26 PM
  • qmacker,


    I am in the same boat. XP Pro SP2 w/ Outlook 2007 connecting to Exchange Server 2003. I also upgraded from a trial version of Office that was preinstalled on my HP Pavillion dv2000 laptop.

    I've been searching for a resolution to this issue since January, and it's now been 7 months. Hopefully I can find someone who will have some MS rep take a look at this thread.

    This is the most up to date thread I have found concerning this topic. Thank you for staying on top of this issue. Your not alone.
    Wednesday, July 23, 2008 11:31 PM
  • I work in the IT department at my college and we have been experiencing this issue since we got Office 2007 a few weeks ago. Outlook 2007 will connect fine to our Exchange 2003 server with many faculty members, but many run into this problem when we upgrade them to Office 2007 and we have to downgrade back to Office 2003. I have tried everything people have mentioned in this thread plus hours of my own research elsewhere, but with no luck, until the other day I think I possibly solved the problem, at least on our campus.

    On a fresh install of Office 2007 or an upgrade from 2003 to 2007, when the user logs on to their profile on the network and opens Outlook 2007, they will get the "
    The action cannot be completed. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action" error. After I hit OK the mail server connection window will appear with the Exchange server set to "MAIL1" and my email address already filled in. If I hit Check Name or just the OK button it will give another error message and Outlook will close and I have to reopen and try again. If I type our actual Exchange mail server address like mail1.ourdomain.com and then click Check Name it will still give the same error. BUT, if I just enter our domain name as the mail server such as ourdomain.com and then click Check Name, it refreshes the window with our actual mail server address in place and is underlined. If I press OK I then see all 3 green check marks on the Outlook Connection Wizard in the background, stating that Outlook 2007 is now connected to our Exchange server and ready to go. I press Finish and all my mail and calendars start to download and Outlook 2007 works like it should. It has been 4 days since I came up with this solution and everything is still working. We went ahead and started deploying Office 2007 on at least a dozen computers around campus and this method has worked on every one that experienced that error message.
    At this point this seems to solve our problem. I hope this applies to others because I understand how frustrated you all are.
    If I run into any problems I will update everyone.

    Saturday, August 2, 2008 12:57 PM
  • Sorry to be such a bearer of bad news: ppunk's post seemed hopeful, but unfortunately his solution didn't work in my situation. :-(  I tried using the "domain.com" only option suggested, but that just brought up the old "Connect to" dialog box - which no matter what is entered into it, never connects (tried all the usual DOM\Username, username@fully.qualified.com, to no avail).

    Now, that follow-up on another "Office upgrade from trial" computer I promised: I managed to get a hold of a colleagues computer that had been upgraded from a factory/OEM-installed trial version of Office 2007, to a full enterprise version. Well, Outlook connects fine to our Exchange server on that computer, so the "upgrade theory" is beginning to look like it holds less water.

    We're over the one year mark now, without a fix from MS.
    Saturday, August 2, 2008 6:08 PM
  • I am amazed and utterly outraged at this issue and more specifically, the lack of comment and support from MS about it. I too have had this issue on Vista (SP1) with Office 2007. I'm actually trying to setup RPC/HTTP for a client and have hit this hurdle. It's most embarrasing as an IT service provider and MS Gold partner to have this issue that MS can't even seem to assist with. I've spent countless hours trying to resolve this, none of which, I can justifiably charge the client for. Who's going to re-imburse me for this lost time/money? Microsoft?? Pfft... Yeah right! I'm yet to use one of our free support tickets on this, as I was trying to see how far I could get on my own, but I think I will need to use one soon as the client can't (and shouldn't) wait any longer for a resolution to this.

     

    I've tried all of the fixes/workarounds mentioned in this thread and none have worked. I can also confirm ppunk's fix didn't work for me either.

     

    I think it's utterly disgusting that MS can leave this as an unresolved issue for so long with only one post from an MS support engineer (Brad) on this entire thread!! WHERE ARE YOU MICROSOFT?!!?! Just because you may be stumped for an answer like the rest of us are, is no excuse to leave us in the lurch... If someone from MS could as least post and advise if this is even being investigated by Microsoft that, at least would be a start. If anyone from Microsoft with half a brain (they do exist I'm sure) read half of this thread they would know that the two KBs don't work in all cases and therefore further investigation is required.

     

    If anyone has any pointers (please don't mention the registry fix as this has already been tried and failed) in how I can get this sorted, I would much appreciate it. My specific configuration is:

     

    Windows Vista SP1 running Office 2007

    PC logging on locally with test account

    Currently setup with NTLM authentication, but have tried Basic as well

    Have tried all combinations of settings in Outlook

    Have recreated mail profile after each change and rebooted PC, nothing different

    Have confirmed RPC.HTTP setup as described here: http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm (have confirned all port numbers, etc are correct)

    Have added the "DefConnectOpt" registry entry

     

    Please help, otherwise I will raise a support case with MS and let you all know the outcome.

     

    Thanks for keeping this thread going a year on so we can all have somewhere to work together on this and hopefully fix what Microsoft can't / won't...

    Monday, August 4, 2008 11:18 AM
  • Thanks devils_fire,

    Let us know how you get on with your paid support. I would have opened one by now but like you I don't want to use one up. I also don't want to waste one, because frankly I have no confidence that they can fix it. Hey, if all of us can't fix it, I don't see how they can. At this stage, I'm just being pessimistic though, so let's hold out some hope for your call.

    (I remember my California history - the infamous Donner Party sent out a rescue mission in December of 1846 called "The Forlorn Hope." Let's hope your path isn't so fraught with frustration!)

    I too have not deployed Office 2007 for this very reason.


    Monday, August 4, 2008 6:08 PM
  •  lsmi4126 wrote:
    Add the RPC and add the DWORD value under it. That's what I did, and it now works!!

     

    I'm going to assume this is a joke.

     

    Can we please have people STOP posting the RPC/DWORD "fix." It's been covered ad nauseum earlier in the post. Also please don't post the "ports" and DefConnect solutions either. We're now trying to find a solution for those of us (many) for whom "none of the above" have worked.

     

    Respectfully,

     

    qmacker.

    Monday, August 11, 2008 10:31 PM
  • You can connect with Windows Vista, but can't connect with windows XP?

     

    SAN certificate principal name window XP outlook issue and solution

     

    Environment:

    Exchange 2007, Office 2007

    You got a SAN certificate like this:

    CN=domain.com

    DNS=webmail.domain.com                  (your Outlook Anywhere entry point)

    DNS=autodiscover.domain.com

    DNS=www.domain.com

    DNS=domain.loc

    DNS=webmail.domain.loc

    DNS=autodiscover.domain.loc

    ECT

     

    Outlook client profile configuration:

    Exchange proxy server:

    https://webmail.domain.com

    Connect using SSL only > Only connect to proxy servers....

    msstd:webmail.domain.com

     

    In Windows Vista this will work, but in Windows XP it won't. In windows XP you can't put msstd:webmail.domain.com in your "Only connect to proxy.." field you have to put msstd: domain.com there, even if it points to the void, doesn’t matter really (ignore that space after msstd: its there to avoid a smilly). In Window Vista you can put msstd:webmail.domain.com there. The same probably applies for other versions of windows, office and exchange (haven’t tried this do). This is because webmail.domain.com isn’t your principal name, domain.com is. I got no idea why Vista allows it. I know this is a bit of RTFM and shame on me, but it’s an extremely easy error to make and if you test under Vista first and it works, well then like me you might search everywhere but right in front of you Smile

     

    Edit: Hmm now I think about it, the same may apply to wildcard certificates. Haven't tested that do.

    Tuesday, August 12, 2008 7:49 PM
  • OK, I didn't call Microsoft, I just couldn't bring myself to do it. However, I have managed to get it working (and it wasn't from adding that bleeping DWORD)!!

    When setting up RPC over HTTP, as previously mentioned, I followed the instructions here. There is a section there that tells you how to configure the RPC virtual directory. It mentions that you do not need to alter the RPCWITHCERT virtual directory as this just references the RPC virtual directory anyway. Well, I thought I'd ignore this advice and I removed anonymous authentication and added basic authentication to the RPCWITHCERT virtual dir (basically mimicked the same setup on the RPC virtual dir).

    I don't know if this will resolve the issue for everyone as there seems to be many factors that can lead to this issue.

    One tip I found that I was about to use, but didn't end up needing was to run outlook with the /rpcdiag switch. This will test all aspects of the RPC connection and tell you exactly where it's failing. This might help some of you as well.
    Thursday, August 14, 2008 2:34 PM
  • Had the same problem, in my case "Configure the RPC proxy server to use specific ports" from http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm did the trick, or perhaps something else, i just re-did each step again. but still have to test on other PCs.

     

    Alex

     

    Wednesday, August 27, 2008 9:57 PM
  • Hi everyone,

     

    Two days ago in our Exchange 2007 training we were facing the same problem of connecting Outlook 2007 to Microsoft Exchange Server 2007.

    We have simulated the scenario in VMWare with Windows Server 2003, Microsoft Exchange Server 2007, Microsoft Outlook 2007 and Windows XP Professional.

     

    We have created a Domain controller in Windows 2003 and created another member server with Windows 2003 and Microsoft Exchange Server 2007. We also installed one client machine with Windows XP Professional.

     

    We tried installing Outlook 2007 in Domain Controller and started configuring it by creating mail profile of administrator in it. Boom !!! and we get the same output everyone has in this forum. It asks for exchange server's username and password again and again. We were not satisfied with the solution " changing the authentication method to NTLM Authentication".

     

    Now, our client machine was also a member of the domain. I created a demo user "spice" in Exchange server and logged in with tht user in client Xp machine. Than I create a mail profile of "spice" and walllah !! it never asks for any authentication and configured successfully with Exchange server. I checked it by opening Outlook 2007 in Xp and it is working perfectly without asking any authentication.

     

     

    The conclusion we derived from it is, when we install Outlook 2007 in a Domain controller, it was the integrated security features of Microsoft Outlook 2007 which are not allowing any user including Administrator to configure outlook 2007 on Domain Controller using exchange server 2007 with "Negotiation Authentication" feature.

     

    When a user login in a client machine which is a member of the domain, with his own credentials he can create his own mail profile and it won't ask for any authentication and configure the profile automatically. But when a user tries to create another mail profile of a different user, it will not authenticate the user credentials to create the profile and continuously asking for the exchange server username and password.   

     

     

     

    Thursday, September 4, 2008 4:35 AM
  • I have the same problem but when I went into regedit I do not have the last folder under Outlook named RPC.  So how am I supposed to add that into the registry without that folder being there.  Any suggestions because this client is very frustrated at not being able to use outlook over rpc on his new laptop.  Any suggestions??

    Thursday, September 4, 2008 2:48 PM
  • Think I've sussed it....

     

    Wait for it...  it's stupid...

     

    when prompted for username/password enter the ip domain name not the netbios name

    eg if your internal ip domain is internaldomain.local (thus your server is server-xx.internaldomain.local) [the netbios domain name would be just internaldomain]

    you would normally (for outlook 2003) enter the netbios domain name followed by the username deliniating the two with a forward slash (\) = internaldomain\username

     

    This DOES NOT (appear to) WORK for Outlook 2007.

    In Outlook 2007 enter the IP "domain name \ username"

    EG: internaldomain.local\username

     

    I think this comes about because 2007 is primarily designed for the newer auth methods of server 2008.

    Or something allong those lines..

    kb927612 attacks the server end and can work in some circumstances by changing/resetting the auth and it's strange that this issue even rears its head on SBS 2003 (my case) as the SBS server is ALWAYS the GC server..

    Certainly kb913843 applies when systems don't have a default gateway.. but ONLY then, and that would be rare on most systems these days.

    Petri's all-in-one article is correct to setup the RPC from one server scenario, however in SBS this is done for us already.

     

    let me know how you get on..

    Dave

    Friday, September 12, 2008 5:47 PM
  • Having issues with recently acquired Lenovo ThinkCentre PC's unable to get Outlook 2007 connected to Exchange Server 2003.  Looking at this particular issue that everyone has been experiencing over the last year or so this issue comes down to a name resolution difference in Vista clients.  I edited the local hosts file on client machines and entered FQDN of mail server, rebooted PC and it all works.  Please refer to how AD has been implemented, I have always practiced using two names when implementing AD one for DNS purposes and the other for NetBIOS.  NetBIOS usually works unfortunately not all the time, but DNS always works.  We have just started to migrate over to Vista and Office 2007 on Laptops and Desktops, the laptop integration progressed without this problem, but ran in to this issue when integrating desktop clients.

     

    I am just a dum I.T. guy and do not guarantee this solution to work for all others due to the different environments that you all are in.

     

    Ppunk, this also worked and saves me time having to edit hosts files on local PC's prior to role-out.

     

    Tuesday, October 21, 2008 4:02 PM
  • Opps, this was posted before on pages 5 or 6, but We only have one exchange server, so I had the rdp ports at our business only open for the internal name, but not the external and internal FQDN.

    So doing a rdpcfg /hd on the exchange server only showed exchange1 with open ports 6xxx. I added entries for exchange1.network.local and owa.network.com for external FQDN using regedit. These changes did not require a reboot.

    Check out this page and the RDPnofrontend tool.

    http://blog.kazmarek.com/2008/06/30/problems-connecting-outlook-2007-with-exchange-2003-using-rpchttps-outlook-anywhere/
    Wednesday, October 22, 2008 5:18 PM
  • Hi all,

    I have had this problem for months now, and reading the forum through the summer left me helpless. Like many, all of the fixes directly addressing RPC didn't work. But, that was until Dave Barnes' post, with alternative solution worked that has worked for me... and yes, I'm almost kicking myself for how simple it is.

    Here's my rundown...
    System specs:
    Vista SP1 Home Premium
    Outlook 2007 Enterprise

    Server Settings and Problem:
    We have a complicated system at our university. We have an exchange server with address: internaldomain1.domainname.com

    We also operate a local server that acts as a RPC proxy for Exchange, as well as a registry of our login/passwords for a range of other network systems. In this case, the local server address is: internaldomain2.domainname.com with username: username

    Previously, my Outlook 2007 configuration would point to the server in the following manner:
    Exchange server: internaldomain1.domainname.com
    User name: internaldomain2.domainname.com\username

    Solution:
    My initial problem was that with my initial settings, Outlook could no longer locate the server (i.e., "Check Names" brought up a window of errors). Upon reading Dave Barnes' post, I figured I should take a look once again at how I am addressing the servers.

    So I did some jumbling around of server names and user names, and found out that my problem was all in a name. Here's my solution sequence:

    Step 1:
    In the Mail Setup Wizard:

    Exchange server: internaldomain1.domainname.com
    User name: username
    Check names works fine, registers my name without a problem

    Step 2:
    In the login/password window:
    User name: internaldomain2.domainname.com\username
    Password as per usual
    Success!!!!

    I am absolutely unclear as to why it's now important to differentiate the "user name" between the server settings and the login/password screen, but this solution was all it took to get it working. I wholly admit this may not apply to others, but hopefully it's another "fix" to add to the quagmire.

    Take care and thanks for the upkeep of this thread!!!,
    Adam
    Saturday, October 25, 2008 5:42 PM
  • I can confirm that none of the last few posts have made any difference.

     

    I can tell you though, when you have a machine that does work properly, it is important to enter the domain\username correctly, however....that is not the problem we are having, nor is it the reason for this post.

     

    This thread exists for those of us who have Outlook 2007 clients that cannot resolve the Exchange 2003 server by IP address even on a LAN.

     

    Tuesday, October 28, 2008 8:56 AM
  • Hi qmacker,

     

    I will try my best to help here from what I've seen of the problem and similar past issues with exchange connectivity.

    I know most of the info and things you've tried are already posted here, but it took me just over an hour to wade throught it all, digest it and fix my problem last time.

    Can you humor me and give a review of your outstanding problem, when it works and when it doesnt?

     

    My general thoughts are that this is an issue at the domain/auth/ip-resolution level either at the client, the exchange server or the rpcproxy, To this end I've put together some questions to help the thought process.

    Please don't be offended, as I know that some of this will be 'suck-eggs'.

     

    (on the client, exchange & RPC_proxy server) Do you have dns resolution (nslookup work correctly)?

    (on the client, exchange & RPC_proxy server) can you resolve the fqdn of the exchange server to ip?

    (on the client, exchange & RPC_proxy server) can you resolve each of the AD role servers (especialy the GC) to ip?

    do you have split exchange/user domains (forrest structure) or are the user accounts in the same domain as exchange?

    Are you running single exchange/rpc proxy (or are these seperate)?

    I assume that it's specific client systems that do not work and not selective user accounts (please confirm)

    are there any firewalls (physical or software) between the exchange, RPC and the GC?

     - What about the other AD role servers?

    What's your method route (click this, click that, enter this here.. etc...) for client setup?

      - do you have a standard document detailing this?

    what exact error text are you seeing?

    Is there anything logged in the eventlog or IIS log on the client (won't have iis log) exchange server and rpc_proxy server?

    What is the map/spread of what will and won't work?

    Having established that (it would appear) that exch03/outl07 combo seems to need the FQDN (domain.local) in the username field, what ip/dns resolution does the exchange server see the users AD domain as?

     - is this lookup working on the exchange and RPC_Proxy server?

     Have you managed to connect euntorage (MAC) to exchange? what versions? and were these internal?

    Where is the (internal) DNS server (locically) in relation to the AD server role holders and Exchange & RPC?

    Is there anything untoward when you run Active Directory Diagnostics.?

     - do these run and produce the same resolts from the AD server, exchange and RPC_proxy?

     - see: [http://waynes-world-it.blogspot.com/2008/03/active-directory-diagnostics.html] for a good batch tool to run

     - it's important that these tests work from the exchange server and possibly the RPC_proxy

     

     

    Most of all, we need to think outside the box on what you've tried and where your specific configuration is set-up as.

    I know that it may take a while to bring all your info together and test things and then post the details, but the more detailed info we have the better.

     

    Dave

     

    Wednesday, October 29, 2008 8:51 PM
  • I am also fighting this problem, and I'm convinced that I'm overlooking something really stupid.  After doing pretty much everything mentioned in this thread, I still cannot get my Outlook 2007 client to connect to my Exchange 2003 server using RPC over HTTP. 

     

    I do get some interesting results, and can't figure out what to look for next.  When I check Outlook's connection status, I see that there are 4 entries showing that the Directory connections are all established over HTTPS, but every time Mail tries to connect it fails.  After connecting via VPN, I looked at the status again and it showed that Mail is connected over TCP/IP (not HTTPS) and everything works fine.

     

    What am I doing wrong?  Why will the Directory connection work, but Mail doesn't seem to want to use HTTPS?  Any advice would be most appreciated....

     

    - Ligonite

    Friday, October 31, 2008 9:23 PM
  • Okay, I've read through this thread (and many others) over the last several hours and pretty much have forgotten most of what people have posted that didn't work, well except for that silly RPC registry thing in which case I'll probably never forget. In any case, I am probably opening up a can of worms but hey, if I help someone...so be it!

     

    I've had the same problem as posted, with additional caveats, I"m not in a corporate environment and I just downgraded from Vista.

     

    I had a Vista machine, with Outlook 2007, connecting to a 2003 Exchange server using RPC over HTTP with no problems. (not a shocker per se...as it was the only thing that worked right...)

     

    Anyway, I wiped the machine, installed XP to the nine's, and then installed Office 2007 thinking 5 minutes later I'd be walking around checking my email. Well it's 7 hours later and I think I have MY problem solved...Maybe it will help someone else.

     

    Had all the same symptoms; "Outlook cannot log on...default gateway", "The connection to the exchange server unavail..", blah blah blah.

     

    I tried the RPC registry, the FQN logon name and server shuffle, pretty much everything in this post and in others I could find, but the thing that did the trick was manually installing the cert presented from the Exchange server. After watching the immediate disconnect everytime O2K7 tried to touch the Exch2K3 server, I figured it was getting there, just getting denied as it was way too fast (use "outlook.exe /rpcdiag" to watch) to dismiss, I just couldn't figure out where the deny was.

     

    My cert is self signed...but I imagine that even with purchased CA, the concept remains the same...O2K7 doesn't trust the cert (I don't know why...)

     

    So here's the deal. I moved my cert to the Trusted Root Certification Authorities and all is well. (okay, not all...am not using ntlm, using basic auth...but that's for another day).

     

    For those of you that aren't as technical as those that aren't me, the EASIEST (not best! but it will guarantee that you are matching cert for cert in the O2K7/Exch2K3 conversation) way is to:

     

    This is assuming you already have the cert imported into your system, if not then skip to 2.

     

    1. Delete the certificate related to your exchange presence (either use the MMC, or just go straight through IE ->Internet Options->Content->Certificates)

    2. Go to your secure OWA website and when it warns you about the cert, click on Install.

    3. When you are asks where to inmport the cert(s), Choose "Place all certificates in the following store" and then click browse to get to the "Trusted Root Certification Authorities" store.

    4. Hit next until it's imported and then go back to your ssl OWA to verify it's imported.

     

    After that, reset all the stuff you've done to the O2K7 client with the except of basic auth, keep that and then try to connect.

     

    Pretty basic, but an easy test...so try it and let me know!

     

    I'm curious if this helps anyone, and if it does...all those out there that actually know what they are doing (not me), please post why this works and how to fix it correctly.

     

    I don't recommend this to anyone as you are using basic auth AND you've installed a cert that doesn't belong? in your root store. Not necessarily GOING to cause a problem, but in the corp environment I can almost hear the shouting.

     

    Oh...there is also the possibility that all of this is bunk and I shoulda had it this way all along...but I'm sure someone will tell me if that's the case..

     

    Good hunting!

     

    Rick

     

     

     

     

    Monday, November 3, 2008 2:09 AM
  •  

    I tried Rick's (Big Headed Freak) certificate idea, and....it didn't work.

     

    Alright, I admit I'm a bit of a grouch, and I'm sorry if I offended AdMaRy and David Barnes (Nobby) the other day. I know everyone is trying their best (see, I'm being nice today).

     

    I am fed up with this stupid problem. I'm annoyed that MS won't acknowledge it. In fact, I think that's what's got me so annoyed - is this lack of acknowledgement. Even a simple, "It doesn't work and we don't know why." would be something.

     

    This is the 2nd intractible problem I've ever had. There are only two computer/software issues I've never been able to resolve satisfactorily. Every other problem I've run into in 20+ years of support, I've always managed to find out or figure out an answer for. Except this one (and another one related to Offline Files).

     

    I guess we'll just hang in here and wait.

     

    David Barnes - to respond directly:

    on the client, exchange & RPC_proxy server) Do you have dns resolution (nslookup work correctly)?
    qmacker: YES. CAN RESOLVE EXCHANGE SERVER FROM CLIENT DESKTOP (ping or nslookup)

     

    (on the client, exchange & RPC_proxy server) can you resolve the fqdn of the exchange server to ip?
    qmacker: YES, BUT NOT FROM OUTLOOK 2007 MAIL SETUP TAB.

     

    (on the client, exchange & RPC_proxy server) can you resolve each of the AD role servers (especialy the GC) to ip?
    qmacker: YES.

     

    do you have split exchange/user domains (forrest structure) or are the user accounts in the same domain as exchange?
    qmacker: NO and YES.

     

    Are you running single exchange/rpc proxy (or are these seperate)?
    qmacker: SBS SERVER. VERY SIMPLE SETUP.

     

    I assume that it's specific client systems that do not work and not selective user accounts (please confirm)
    qmacker: CORRECT. NOTHING WORKS FROM THIS PARTICULAR INSTANCE OF OUTLOOK 2007 ON THIS PARTICULAR MACHINE.

     

    are there any firewalls (physical or software) between the exchange, RPC and the GC?
    qmacker: NO.

     

     - What about the other AD role servers?
    qmacker: NO.

     

    What's your method route (click this, click that, enter this here.. etc...) for client setup?
    - do you have a standard document detailing this?
    qmacker: DOESN;T MATTER. I'VE TRIED EVERY WAY TO SUNDAY. THEY ALL FAIL.

     

    what exact error text are you seeing?
    qmacker: "The action cannot be completed. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action."

     

    Is there anything logged in the eventlog or IIS log on the client (won't have iis log) exchange server and rpc_proxy server?
    qmacker: NO, NOTHING.

     

    What is the map/spread of what will and won't work?
    qmacker: DON'T KNOW WHAT THAT MEANS.

     

    Having established that (it would appear) that exch03/outl07 combo seems to need the FQDN (domain.local) in the username field, what ip/dns resolution does the exchange server see the users AD domain as?
    qmacker: DON'T KNOW WHAT THAT MEANS.

     

     - is this lookup working on the exchange and RPC_Proxy server?
    qmacker: IT'S A SINGLE SBS SERVER.

     

     Have you managed to connect euntorage (MAC) to exchange? what versions? and were these internal?
    qmacker: YES. ENTOURAGE 2004 FOR MAC.

     

    Where is the (internal) DNS server (locically) in relation to the AD server role holders and Exchange & RPC?
    qmacker: IT'S A SINGLE SBS SERVER.

     

    Is there anything untoward when you run Active Directory Diagnostics.?
    qmacker: NO.

     

     - do these run and produce the same resolts from the AD server, exchange and RPC_proxy?
    qmacker: IT'S A SINGLE SBS SERVER.

     - see: [http://waynes-world-it.blogspot.com/2008/03/active-directory-diagnostics.html] for a good batch tool to run

     - it's important that these tests work from the exchange server and possibly the RPC_proxy

    Monday, November 3, 2008 9:24 PM
  • Hi qmacker.

     

    Assumptions etc (correct me if I'm wrong)

    SBS makes things very straightforward (or should do) as you have a 'known' setup with many less variables than others.

    I'm assuming you're not Premium with ISA in the way.

    I assume that you're not using the default .local TLD for the internal domain (as you have connected MAC's) and are using something like mydomain.internal

    Being SBS you don't need to go through Petri's exchange proxy setup, as it's already done for you.

    As you have other outlook clients connected over https it's safe to assume that SBS is up and running ok.

    As other clients (outlook 2003) work over https, then outlook mobile access must have been enabled when you ran CIECW on SBS.

     

    My SBS 'base' setup rules/mods/methods are:

    1/ I use a proper internet domain internally. - I purchase the .net domain (myco.net) and point an A record at the servers internet facing IP address. so that servername.myco.net points to the server from the internet AND internally. This allows laptop outlook clients to seemlessly move from internal to external without the need to switch profiles etc..

    2/ the base SBS setup seems to lose it's DNS suffix from time to time. This is evident when you start nslookup and it reports the name of the default server as unknown. Temporarily this is resolved by doing "ipconfig/registerdns" on the server.

    The permament fix is to add the DNS suffix into the network card IP configuration in both the 'append these DNS suffixes' and 'DNS suffix for this connection' on the SBS server. - this has an impact on owa, oma, and outlook over HTTPS logins. (user/passw unknown on some occasions when the dns suffix is unregisterred)

    3/ add the SBS server FQDN [servername.myco.net] to IE's 'trusted' zone on the client.

    4/ (when ie7 on client) add the SBS server FQDN [servername.myco.net] to the pop-up blocker whitelist (website to allow)

    5/ manually install the SBS self-signed-certificate to the 'trusted root certification authority' on the clients.

    SBS will have placed a copy of the cert (.cer file) in \\servername\clientaps\SBScert\sbscert.cer - you can use the MMC on the client to add this to the 'computer account' 'trusted root certification authority' then reboot the client [for good measure].

    Pointing a browser at https://servername.myco.net/remote should no longer present a certificate error and should show as a trusted zone site.

    6/ ***this is a sidebar to the current issue/problem we are chasing but is so CRITICAL I need to bring it up here***
    Fix the DNS client and server source port randomisation problem on (at a minimum) SBS server.

    see <http://bitsolve.spaces.live.com/blog/cns!D0597DCC1B3A70EF!288.entry>.

    Basicly the recent DNS fixes REALY bugger things up. The DNS server AND client randomly allocate 2,500 ports (each) so that they can randomise the source port they perform the DNS lookup request from (yes DNS server does issue requests). On SBS these ports that are allocated randomly at boot/service start can and do include critical ports like 4,500 [IPSec]. In particular if port 4500 gets allocated, IPSec will fail to start and the server will refuse ALL ip traffic - err server is OFFLINE till you reboot and it randomly allocates a different set of ports..

     

     

    Connecting the Outlook Client

    ----------------------------
    My test setup..
    SBS 2003 (NO ISA)
    XP Pro SP2 (VM)
    Office 2007
    ----------------------------

    (On the Client)

    goto the 'CMD' prompt
    enter: nslookup
    - The 'Default server:' should show the correct FQDN of your SBS server. [EG. servername.myco.net]
    Exit nslookup
    Close 'CMD' prompt

    Fire up IE and enter the FQDN (internal) address of your SBS server '+/remote'
      EG:  https://servername.myco.net/remote
    - IE should go atraight to the user/passw page (form) and NOT squark about certificate errors etc.
    Close IE


    Start, control Panel, Mail
     [if present] remove any profiles
     Add...
      Enter a profile name and click "OK"
      The 'Add New E-mail Account' wizard screen appears,
       Tick the "Manually configure server settings or additional server types", and click on "Next >"
      Select 'Microsoft Exchange' and click "Next >"
      The 'Microsoft Exchange Settings' screen appears
       Enter the Internal name of your SBS server [eg: servername.myco.net]
       Leave 'use Cached Exchange Mode' ticked
       Enter the users mailbox name (look in system manager at the mailboxes, as this may not be the same as the logon username)
       ** Do Not click on 'Check Name' **
       Click on "More Settings..."
       - If you get a 'Connect to ...' dialogue box, click on 'Cancel'
       - You (may) get a 'The action could not be completed. The connection to Microsoft Exchan...' modal box - click "OK"
       - You (may) get a "Microsoft Exchange" window withe just a 'General' tab and boxes for the server and mailbox and a 'check name' button.. - Click on "Cancel"
       - You then should get the (more farmiliar) 'Microsoft Exchange' window with the General, Advanced, Security Connection and Remote Mail tabs.
         Goto the 'connection' tab
          Tick the box (at the bottom) 'Connect to Microsoft Exchange using HTTP'
          - The 'Exchange Proxy Settings Button' should become 'un-greyed-out' - Click on it
           We get to the 'Microsoft Exchange Proxy Settings' window
            For the "Use this URL to connect to my proxy..." - enter the FQDN of your exchange server. EG: servername.myco.net
            Tick BOTH "on fast networks..." and "on slow networks..."
            Change the 'Proxy authentication settings' (at the bottom) to "Basic Authentication"
           "OK"
         "OK"
       We should be back at the "Add New E-mail Account" window.. 
       "Next >"
       "Finish"
     "OK" out of the "Mail" (profiles) window
    Close Control Panel


    Start Outlook 2007
     some 'configuring outlook for the first time' etc windows come and some go..
     Eventually you should get a standard Username/Password window.
     Enter the username in the format domainname.tld\username    [EG: myco.net\myuser]
     Enter the password
     Click OK
    - You may be prompted to enter the user/passw again (the user will already be filled in wrong)... - Enter the same again..!! (why it sometimes asks twice, I haven't figured out yet)
    After the wait for the various progress boxes etc, you should be running in outlook, all be it, slowly at first, as it synchronises the various folders.

    If you need any screen-shots etc, let me know..


    Key points, re connecting client

    Mailbox name will most probably be different to the AD Username
    Don't click on 'check name'
    Persist in telling it to 'cancel' the 'check' it tries to do.
    Enable HTTP (tick box on connections tab)
    Enter the SBS servers FQDN (servername.domainname.tld)
    Tick both connection boxes to FORCE https in all conditions
    Change Auth to 'Basic'
    Persist with entering the User/passw in "domainname.tld\username" format (may get more than one prompt)

    - If it prompts for user/passw with the username already filled in - IGNORE it! Fill the username in as described above.

     

    Phew..

    One office 2k7 install on VM and run through the setup notes later...

     

    I sincirely hope this works for you..

    Dave

    Tuesday, November 4, 2008 6:36 PM
  • It wasn't working for me. My GC is two domain controller not exhange. I got same error message on outlook (error code 8)

    We were running Exchange 2003 SP2 and Outlook 2003/2007. Recently our ssl self cert was expired and exchange server also was configured with certificate authority. So we renew certificate by local certificate authority  and generate certificate for IIS.

    Now our remote users are not able to connect with rpc-over-https connection (some pc was joined with AD some are not) and mixing of Windows XP SP2 / outlook 2003 /2007 and Vista. I have install newly created *.cer to trusted root on client machines but no avail.
    Interestingly those Vista laptops I have recently joined with domain and configured outlook rpc-over-https  is working.
    I have been searching through web but no clue to resolve my issue. Appreciate if anyone can assist me.
    Thank you.
    Friday, November 7, 2008 9:41 AM
  • It wasn't working for me. My GC is two domain controller not exhange. I got same error message on outlook (error code 8)

    We were running Exchange 2003 SP2 and Outlook 2003/2007. Recently our ssl self cert was expired and exchange server also was configured with certificate authority. So we renew certificate by local certificate authority  and generate certificate for IIS.

    Now our remote users are not able to connect with rpc-over-https connection (some pc was joined with AD some are not) and mixing of Windows XP SP2 / outlook 2003 /2007 and Vista. I have install newly created *.cer to trusted root on client machines but no avail.
    Interestingly those Vista laptops I have recently joined with domain and configured outlook rpc-over-https  is working.
    I have been searching through web but no clue to resolve my issue. Appreciate if anyone can assist me.
    Thank you.
    Friday, November 7, 2008 10:22 AM

  • Hi robiul,

    On the affected clients (that cannot connect with rpc-over-https)
    ..
    Can you point the web browser at https://servername.yourdomain.tld/exchange [fill in your correct address for your server]
    ???
    do you get certificate error?

    If you get certificate error.. view the certificate and check that the server is actually using the correct (new) cert
    If it is the correct (new) cert, then it just needs installing properly on the clients into the computer root certificate store.
    Use the MMC certificates snap-in, check both the system and user private and 'root certification authority' stores (4 to check) you probably have the old cert in the user store or the private store which is blocking access to the new cert which should be in the computer 'root certification authorities' store.

    Dave
    Friday, November 7, 2008 6:18 PM
  • We're no closer to getting this problem resolved. Let me recap and resummarize the problem:

     

    1. Some Outlook 2007 clients cannot connect to Exchange 2003 Server using HTTPS.
    2. Outlook 2003 clients can - repeat CAN - connect to the same Exchange 2003 Server using HTTPS.

    The (Outlook 2007) machines that cannot connect, have no problem connecting to Outlook Web Access using IE. There are NO certificate problems, the domain and username can be entered every way to Sunday, basic or NTLM authentication set - it doesn't matter - nothing works.

     

    New posters need to carefully re-read the last seven pages of posts, so we don't repeat anything.

     

    Thank you for all your help and kind efforts.

     

    P.S. Microsoft - HELLO? It's November 7, 2008. This post was started on May 3, 2007. Let's not make it two years without a solution!

    Friday, November 7, 2008 8:19 PM

  • Hi qmacker,

    I'm as bemused as you.. I've seen this and 2003's various 'quirks' before, but usually getting back to the basics fixes it.
    Grrrr... so frustrating.
    The other painfull bit is, it appears not work if you turn off SSL (well it didn't for me) as I would want to look at what was happenning with something like netmon 3.2.. That way I can watch the auth request etc.. With it all locked up inside SSL we can't look in and see what's happening. (or NOT happening)..

    I've sat looking at the screen for over half an hour, racking my brains, trying to think what we've missed..
    Your server MUST be ok, because;
    1/ its SBS
    2/outl03 clients work over https
    3/ ergo servers self-signed cert must be ok
    4/ you can goto the OWA web (https://.../exchange) without cert error etc..

    Can you look at both the system (local computer) and user (current user) cert store on the client in question (mmc, certificates snap-in)...
    Trawl through all the stores and remove any duplicates. The servers cert should be in the Local computer, trusted root certification authorities store only.
    Check that you can still goto https://.../exchange after..

    This points to something on the client (doh.. I know..) But what???? grrr
    something is blocking or interfering with client communication.
    Things I would investigate:
    AV (process, access exceprtion blocking)
    AV blocking http/https access
    client firewall software of some sort

    The question I have here at this point is...
    Does Outlook 2007 natively use TLS (SSL) or parse it through the client systems DCOM/COM sub-system, or some other method.  (.net???)

    Are you in the UK?
    I'd love to 'get my hands' on this as it is very challenging/frustrating!

    Dave

    Saturday, November 8, 2008 4:42 PM
  • Methinks it's time to get the credit card out and call PS
    You may be able to get the call as 'free' if it's and installation (setup) issue. Hmm maybe..

    Yes I think you may be free on the call to product support as it's never worked and you are just trying to setup the software (outlook) for the first time on that system.

    Dave

    Saturday, November 8, 2008 4:47 PM
  •  qmacker wrote:
    If I hear about this DefConnectOpts regkey one more time, I think I'm gonna shoot myself.

     

    DITTO!

     

    I have tried every single method in this thread and numerous others.

     

    One question: When I attempted to run the Setspn -L ExchangeServerName I receive a

     

    FindDomainForAccount: DsGetDcNameWithAccount failed!

    Cannot find account ExchangeServerName

     

    I ran Setspn from the Root (cSmile also on the drive that houses Exchange (dSmile

     

    No Luck.

     

    PS. I'm spending the $250.00 to call MSoft, hopefully I'll get a resolution strategy that is different from 'DefConnectOpts'

     

     

     

     

    Monday, November 10, 2008 4:01 PM
  • The problem appears to be related to the authentication method used.

    Make sure that the rpc virtual directory has basic authentication enabled.

    The outlook 2007 client, connects by default using ntlm authentication, change this to use basic authentication.

    Ensure that the username is specified in the correct format  domain\username.

    Tuesday, November 11, 2008 12:13 PM
  • Okay: laptop 1 (XP, Outlook 2007, Exchange 2003, *.mail.domain SSL issued from Network Solutions)

     

    'The action cannot be completed. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action'

     

    'User Name or Server Name cannot be resolved'

     

    Yes, I have read every page of this thread at least 3 times. The closest 'maybe' was the setspn.exe thought. This is a SBS, doesn't seem like setspn.exe is applicable (plus it didn't work anyway).

     

    Laptop 2 (Levono Thinkpad, Vista Business, 64 bit, Outlook 2007)

     

    Same Error Message

     

    Basic Authentication on both machines

    msstd: mail.doman.com

    URL to Connect: https://mail.domain.com

     

    I'm starting to think it's a Server Issue.

     

    You know, I get very tired of MS's 'Upgrade' answer.

    Tuesday, November 11, 2008 4:56 PM
  • Hey Kathryn -

    Did you try changing the authentication type to "Basic?"

    Just kidding!

    Let us know how you get on.
    Tuesday, November 11, 2008 9:24 PM
  • Just a thought...

    Have you guys changed your security certificate on SBS at any point?
    Did you use CIECW to create/add the new cert?
    What address is the cert issued for?
       - internal or external or do you use uniform internal/external DNS naming.
    Have you, at any point, configured things manually on SBS or have you always used the wizards?

    Dave

    Wednesday, November 12, 2008 11:43 AM
  • Well, I have it working (partially)

     

    I logged the XP laptop into the VPN and then connected...it worked.

     

    Firewall issue? i haven't seen anything that says to set specific ports open on the firewall.

     

    Thoughts?

    Wednesday, November 12, 2008 2:17 PM
  • Hi KathrynLSullivan,

    Outlook detects the connection type. LOL..
    Unfortunately, an internet connection (these days) is detected as a "fast network".

    From my notes (on page 7)
    Tick BOTH "on fast networks..." and "on slow networks..."


    Does this solve it for you?

    Dave.

    P.S. I'm still stuck on qmacker's version of this problem. I just don't get where it's gone wrong for him. With SBS if you run CIECW and correctly put the external address of the server in (usually the external name or ip of the firewall/router) and enable the port forwarding on the router/firewall (as per the help inside CIECW) [it prompts.. do you want to see instructions on what to set your firewall to do .. or suc like words]
    Then follow my notes (to the letter) installing the cert on the client, adding the zone settings, then stepping through outlook and setting the servers address as the proxy (BTW you don't actually need the MSSTD:.... bit), ticking both slow and fast and setting basic auth.. It does work 99.99% of the time (ok Outlook 2007 needs the username putting in in a different way to 2003)

    Wednesday, November 12, 2008 6:02 PM
  •  

    Followed this articles at:

    http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

     

    Noticed way down the article where it talks about doing the registry hack for the static port on "all" global catalog servers.

     

    Once I added the hack to my additional domain controller (not Exchange Server, but a GC). The connection finally worked.

     

    Also made sure to specify the Exchange Server's Netbios name in the connection profile box where you put in the Exchange Server and the Username. The proper credentials that finally worked were "DOMAIN\username". The AD name would not work, only the Netbios version of the AD name.

     

    We struggled with this for 6 months. Now we are fixed at least.

     

    P.S. Launching Outlook with the "Outlook.exe /rpcdiag" really helped.

     

     

    Wednesday, November 12, 2008 6:24 PM
  • Hey everyone.  I see this has been going on a long time; over a year.  I believe I have found a solution that will solve this dilemma for most of you, at least for, IE7, Vista and Office 2007.  It works with the trial version, so, I don't believe Office to be the culprit.  I'm going to write a paper on this because, like you experienced, there was no solution to be found.  It's a complicated explanation but it's a moderately difficult fix.  No rocket science involved.

    What I found was nobody knew what the cause of the problem was and therefore nobody could come up with a fix.  All of us were making the same configs we had made for XP/MSO2K3, but that didn't work.

    The cause:  The certificate is not in the Trusted Root Certification Authority - I know you have read that before but it's really not there and I'll show you how to verify it.  Using the MMC\Certificates snapin is not the way to do it.

    It's not there.  Yes, I know you entered entries into your trusted hosts.

    http://serverNetBIOSName
    https://serverNetBIOSName
    http://publicFQDN
    https://publicFQDN

    ...and I know you went to:

    https://publicFQDN/Exhange or
    https://publicFQDN/RPC

    ...entered in: domain\username and password and for OWA it logged you in but for RPC it prompted for credentials once again, and then you clicked cancel.

    Then, with your address line now red in color, you clicked on the Certificate error, chose to View Certificate and installed it into your Trusted
    Root Certification Authority.

    Yes, the Trusted
    Host entries are required so you can install the certificate.  The problem is, the certificate is not there, even after it tells you it installed it successfully.  What makes it confusing is now you can get to OWA.

    That is the cause of the problem.

    You can load the MMC and add the Certificates snapin and peruse the certificates you have installed and it will show you it's in the Trusted
    Root Certification Authority.  However, if you go to:

    (In IE7)
    Tools/Internet Options/Content tab/Certificates button/Trusted Root Certification Authorities, you won't find it.  I didn't.

    If you don't see it there, looking in IE7, continue reading, otherwise, this may not be a fix for you.

    The server setup, for my customer, is Windows Server 2003 Standard.  Unfortunately, since it's not SBS, you have to go through the petri.co.il document to make sure your server is setup properly.  My only change was to add the publicFQDN ports 6001-6002, 6004 in the registry but I don't think they were required.  I did everything manually and didn't run any wizards or use any tools.  The petri.co.il document, although very helpful, is confusing and unorganized.  It's do this...blah blah blah....OR... do this... Well, ***, I just did the first one and now I find an easier way?  List the options first, please.

    Since I knew my certificate was not in my Trusted Root, because it's still not showing there in IE7, but does in the MMC\Certificates, I looked for a way to import it directly since installing it by going to the publicFQDN didn't work.

    I found a document that said I could go to http://publicFQDN/certsrv

    I tried that but got an error somewhere in the process.  I don't remember the error but you'll know if you get it.  To get around that error, I found a document, either MSFT pointed it to me from the link above or I searched for it.

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

    In this document is a link to get an update:

    x86/32-bit version:
    http://www.microsoft.com/downloads/details.aspx?FamilyId=FFAEC8B2-99E0-427A-8110-2F745059A02D

    Before you apply this, backup this area:

    %systemroot%\system32\certsrv

    I copied that in WE (Windows Explorer) and pasted it on the root of the drive.  c:\certsrv

    I then ran the update.  It says you may have to reboot, I didn't.

    I was then able to get to certsrv, https://publicFQDN/certsrv
    You will be prompted for a login, I used the same credentials I was using to install the certificate.

    The page heading is: Microsoft Active Directory Certificate Services - NetBIOSServerName

    Click on: Download a CA certificate, certificate chain, or CRL

    CA certificate: box should list: Current [NetBIOSServerName]

    Encoding Method: DER

    Click: Download CA certificate

    You'll get a file download warning popup:

    Click Save

    The filename offered to me was: certnew.cer

    I saved it in [primary drive:]\username\documents

    It should tell you the download was complete.

    In IE7:

    Tools/Internet Options/Content tab/Certificates button
    Click Import button
    Click next
    Browse to get your certnew.cer certificate file
    Click next
    Click the radio button Place all certificates in the following store
    Click browse and choose: Trusted Root Certification Authorities
    Click OK
    Click next
    Click finish

    You should see: The import was successful.
    Click OK

    Now verify that the certificate is in the Trusted
    Root Certification Authorities.  You will see the NetBIOSServerName in the list under Issued TO and Issued BY.

    You can now open up Outlook, put in your credentials and you should be connected.

    Let me know if you have any issues along the way as I may have experienced them also.

    Good luck.  I hope you're successful.

    Saturday, November 15, 2008 6:18 PM
  • David...

    You should use the msstd and you should not enable using it on a fast network or you will be prompted for credentials all the time because you're using Basic Authentication.

    Monday, November 17, 2008 7:59 PM
  • Roland,

    Agreed, you should use the MSSTD, but you don't have to.
    When diagnosing issues etc (which we are here) one tends to not use the optional extras.



    Yes, selecting "FAST" does force authentication all the time.
    But with the 'fast networks' switch.. Well you HAVE to tick this unless the laptop/system only uses dialup or a very slow and directly connected (not via router/firewall) ADSL when it is roaming.
    Home LAN (behind the router) is [normally] detected as a 'FAST NETWORK'
    Some G3 connections detect as FAST some as SLOW, seems to vary and not be consistent for this type of connection.
    Even a wireless hotspot [almost always] will be detected as a 'fast network'.

    The 'FAST NETWOK' detection, I have learnt from using it in action, and supporting many remote users.
    This may not be the intention of the setting (from MS), but this is what I've seen in action.
    There must be some detection tecnique in place, but FAST/SLOW is not how one wants to use the RPC_OVER_HTTPS.
    What we really are trying to do is switch between "INSIDE" and "OUTSIDE" and fast/slow does not realy work reliably.
    Even switching bassed on IP subnet would not be 100% reliable.
    Measuring the IP hops to the server could work, but would be painfull for large organisations with wans and remote offices.

    Plus you will still be prompted for credentials if the machine is not a member of the domain.
    Home PC's will not be members.
    That then leads on to the laptop "member" argument.
    I have found it varies, dependant on intended use as to whether laptops are actually domain members.
    So many users complain of slow performance and eronious errors, that I tend to NOT join laptops to the domain.
    I manage them as untrusted guests, as one can't be sure what they will catch at that Singapore Airport wireless hot-spot.
    The member or not question is one for each case on it's merrits.
    However if it's not a member, you still will have to enter the credentials.

    User education is also an issue.
    As most 'remote' users tend to be in the upper echelons of management, they seem to commonly, never have time to go on the staff orientation course or to actualy understand what they are doing with the computer. (the senior management user syndrome). Ergo having two different logon methods (with prompt for credentials and without prompt) causes issues.
    Too many desperate calls from frankfurt airport at 7pm saying the server's down and they urgently need the document in outlook.. When it's just prompting for user/pass and they are not used to that.. (or conveniently forgot)!!!

    Dave
    Tuesday, November 18, 2008 2:18 PM
  •  Roland Hall wrote:

    The cause:  The certificate is not in the Trusted Root Certification Authority - I know you have read that before but it's really not there and I'll show you how to verify it.  Using the MMC\Certificates snapin is not the way to do it.



    Almost...
    (Back on page 6) in my post; Rule 5: ...use the MMC on the client to add this to the 'computer account' 'trusted root certification authority'...

    Perhaps I did not explain.. There are TWO certification trees. One for the User and one for the computer. Within the MMC you have to add 'certificates' twice and select personal then computer.
    PLUS the 'trusted root certification authority' (in both computer and user trees) is mashed with the 'personal' certificate store when looking up a cert..
    Common causes for problems is a personal cert (done through IE, view cert, install, add, ok.. without selecting the store).
    Also IE route will add the cert to the user tree not the computer tree.
    In the MMC you need to Import the cert to the
    'trusted root certification authority', then move (drag & drop) to the computer 'trusted root certification authority'.
    One needs to trawl through ALL the stores to ensure there are no rogue entries hanging on.
    Common causes of problems when a cert is re-created for whatever reason.

    Dave
    Tuesday, November 18, 2008 2:34 PM
  • For all those guys who have got the following problem...

    Windows Vista
    Uninstalled O2007 and installed O2003
    Trying to connect to exchange via RPC over HTTPS and it does not get connected

    Try doing the following...

    1. Open internet explorer, Go to TOOLS > INTERNET OPTIONS > CONTENT TAB > Click on CERTIFICATES > Click on TRUSTED ROOT CERTIFICATION AUTHORITIES Tab
    2.
    Scroll down to the certificate which corresponds to your OWA  (If you don't see the certificate, you need to install it)
    3. Click on the ADVANCED BUTTON
    4. In the following window, enable all (Tick everything), Including SECURE EMAIL and OK it.

    Try configuring your mail through Control panel > Mail (Skip this if you had already configured)

    Run outlook with rpcdiag...

    outlook.exe /rpcdiag

    The rpc dialog should show

    The conn column in the Exchange server connection status should show HTTPS

    Hope it solves your problems, it worked for me...  Smile

    Sunday, November 23, 2008 8:15 AM
  •  

    I have been dealing with the same issue today and have been reading this forum. Man do Microsoft have alot of answering to do.

    Anyway I have managed to get mine working. The symptoms were as follows

    -Vista Business OS

    -Office 2007 (Outlook)

    -System on a different domain to where Exchange 2003 is hosted

    -Outlook /rpcdiag showed no HTTPS connections although both use HTTPS on fast and slow connections was selected.

     

    Resolution for MY issue (may help I dont know)

    -create VPN to site where Exchange 2003 hosted

    -open Outlook and allow to set itself up

    -Shut down Outlook and disconnect VPN

    -reopen Outlook and RPC/HTTPS is now working

     

    Dont ask me why this works but it appears it does. I hope this is useful for those who are still having this issue or for any who have just begun to have this issue and are looking for a potential 'quick fix'.

     

    qmacker is a real trooper and I hope this helps resolve your problem. I realise its a *** of a work around if hundreds of systems being affected, but maybe this will help.

     

    Cheers

     

    Hayden

    Wednesday, November 26, 2008 2:02 AM
  •  

    Under

     

    \HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

     

    check there is a REG_EXPAND_SZ called AppData. The actual value seems not to be not important, but

    %USERPROFILE%\something

     

    I realise this may not be the solution for everybody. If it's been posted way back on page 5 please don't shout at me.

     

    I've just run a pilot of 50 users to Outlook 2007, Exchange 2007, and 4 out of 50 had the issue described all over the internet, where Outlook prompts continuously for authentication while creating a profile.

     

    We isolated the HKCU registry.

     

    We took a snapshot of the reg that wouldn't work, and one that did, and compared the differences.

     

    When we add the AppData value, it works, when we remove it, it fails.

     

    We've tested this and it seems to be reproducable

     

    Hope this is of some help to people.

     

    As is often the case, in researching possible solutions for an issue I had on a project I found 20+ possibilities, none of which worked for me.

     

    I also found 20 similar but not exactly the same issues.

     

    I appreciate I may not exactly fit the description of the problem in the thread, but this is the thread that proved the most usefll, and seems to be the most complete, so I figured I'd add my findings here.

     

    Hope it's not out of place.

     

     

    Friday, December 5, 2008 1:45 PM
  • Interesting,

    Qmacker (& others) - Does this fix your issue??

    A bit of sideways research shows KB886549.
    This indicates that:
     On XP this should be "%USERPROFILE%\Application Data"
     On Vista this should be "%USERPROFILE%\AppData\Roaming"

    It would be worth looking at the other keys as well. (see http://windowsxp.mvps.org/usershellfolders.htm)
    My bet is that without the key entry the roaming data cannot be stored, and hence the constant prompting for credentials.
    See also http://www.tech-archive.net/Archive/Outlook/microsoft.public.outlook.installation/2008-09/msg00314.html for some paralel discussion of outlook 2003's failure to remember passwords on vista. This is prety much the same authentication module type problem that we have seen, just a variant manefestation.

    This coupled with the other 'trip-you-up' settings that MUST be 100% right first before it will work, make it sokmewhat of a minefield of hit-and-miss to get it working.
    Things Like..
      1/ (exchange) Servers SSL cert installed into the correct 'Local Computer' (not user), 'trusted root certification authority' (not personal).
      2/ using the correct mailbox name (not the logon name)
      3/ setting the connection proxy settings to use http for BOTH slow and fast networks.
      4/ (For Outlook 2007 to exchange 2003) enter the username in "DNS.DOMAIN\USERNAME" format (rather than NETBIOSDOMAIN\USERNAME format)
      5/ (and now we find that) HKCU\Software\Microsoft\CurrentVersion\Explorer\User Shell Folders\appdata *MUST* contain a suitable value.

    David Barnes
    Saturday, December 6, 2008 3:08 PM
  • Okay, I have some changes, and something to note.

    First of all that key path (for me anyway) is wrong, and should read:

    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

    (Note: "\Windows" was left out)

    In my case the AppData key is there, and its value is exactly:

    %USERPROFILE%\AppData\Roaming

    So, no joy here.

    Now, something else of interest, which leads me to believe even more that this is a **client side** problem, and has always been a client side problem. Either the problem is with Vista, or Outlook 2007. I says this because I recently migrated our SBS 2003 server to an SBS 2008 server, which uses Exchange Server 2007.

    Guess what? It still doesn't work! And it still doesn't work on just this one, non-domain member, Vista Home Premium machine, with Microsoft Office Enterprise 2007,
    on the same LAN. Incidentally, we can connect fine to Office Outlook Web Access under Exchange 2007, from the "bad" machine, just like we could connect fine to the old Outlook Web Access under Exchange 2003, from this same (bad) machine.

    NOTE: I have other non-domain member machines, also running Vista and
    Office Enterprise 2007, and they can connect no problem.

    So, for me anyway, we now have the addition of this one machine not working with Exchange 2007 either. I really don't see this as a server issue.

    Let's keep plugging away. Thanks for your help, everyone.

    (See? I'm being nice today!)


    Saturday, December 6, 2008 11:14 PM
  • I was seeing the same problems as everyone else.  Saw the information on the User Shell Folders and did some comparison between a machine that works and the machine that didn't.  The one that didn't work was missing all the keys except one.  Imported the REG file listed at Reset the Shell Folders paths to defaults  (windowsxp.mvps.org) and immediately Outlook 2007 configured and ran all the way through the setup process. 
    Thursday, December 11, 2008 6:27 PM
  • I had the exact same symptoms (using a single server config).  My problem was me.  Our old internal domain was "oneword".  When we went to AD, made it "one.word".  While doing the reg changes for rpc proxy ports, I inadvertently used "oneword".  It would work with outlook 2003 but not 2007.   2007 would work while on the lan.  Put the "." in and success.  I have since set it up on several vista/outlook 2007 machines both domain members and non with success.
    I hope this is helpful in someway to someone.

    good luck,

    Mike 
    • Proposed as answer by ft88plc Sunday, March 1, 2009 1:23 PM
    Saturday, December 20, 2008 8:18 PM
  • Just want to say that after struggling with this all weekend, I now have it working. I followed Petri.co.il mainly, especially what he had to say about FQDNs (internal and external) as well as all the registry checks, and it kept failing.
     
    http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

    I finally recalled a problem from when I setup OWA and various OWA-related virtual web directories under the main Default Web Site (where the RPC virtual directory sits) needed to have the correct IP access permissions) and that particular problem was finally solved with the correct permissions.
     
    At that time, I had used the W3SVC logs to solve it then, so I checked them this morning, and there was the problem.... finally!

    I looked in C:\WINDOWS\system32\LogFiles\W3SVC1 and the log file with todays date: 

    2009-03-01 12:50:27 W3SVC1 192.168.88.90 RPC_IN_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6004 443 - 86.154.xxx.xxx MSRPC 403 6 0 1744 295
    2009-03-01 12:50:27 W3SVC1 192.168.88.90 RPC_OUT_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6004 443 - 86.154.xxx.xxx MSRPC 403 6 0 1744 288
    2009-03-01 12:50:27 W3SVC1 192.168.88.90 RPC_IN_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6004 443 - 86.154.xxx.xxx MSRPC 403 6 0 1744 295
    2009-03-01 12:50:27 W3SVC1 192.168.88.90 RPC_OUT_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6004 443 - 86.154.xxx.xxx MSRPC 403 6 0 1744 288

    NOTE: the "403 6" after the MSRPC on each line, effectively an HTTP response code indicates something like "forbidden access", due to the source IP address of the client (86.154.xxx.xxx)

    For the solution, I checked the properties of the "rpc" virtual directory under the Default Web Site in IIS and went to Directory Security and then edited "IP address and domain name restrictions". I removed the current denial rule in there which was effectively only allow local access, and said grant access to all.

    Then, I rechecked all settings on my client just for good measure:

    Windows XP, fully service packed and up to date. Office 2007. Windows Server 2003 SBS, fully service packed and up to date.

    1. I have now removed my server SSL certificate from my local PC certificate store (it was in the Local Computer Certificate Store under Trusted CAs, but that was obviously a red herring (blind alley). My server certificate was issued by a CA that was already in the list of Trusted CAs.

    2. In account settings:
        a) Exchange  Server is NETBIOSSERVERNAME1.mydomain.local
        b) Username is my full name John Doe
        c) More settings:
            i)Security - Encryption is ticked and Logon network security is Negotiate Authentication (seems to work with this or NTLM)
            ii) Connection (the important one)
                 - Outlook Anywhere box ticked to connect using HTTP
                 - click on Exchange Proxy settings and enter EXTERNAL FQDN into URL box,
                    so in my case "e.mydomain.com".
                 -  I happen to have the "fast" box unticked and the "slow" box ticked - it seems
                     to work with the "fast" box ticked or not - evidenced by running outlook in RPCdiag mode:

                    "c:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE" /rpcdiag

                 - I don't have the next box "Only connect to proxy servers...." ticked, as it was
                   not ticked by default when I first enabled Outlook Anywhere in Outlook 2007.
                   Another red herring.

    VERY IMPORTANT - I HAVE TO HAVE "BASIC AUTHENTICATION" FOR PROXY AUTHENTICATION SETTINGS. NTLM WILL NOT WORK (I remember reading somewhere about why/how NTLM doesn't work for this part.)

    Anyway, now, finally working - the login name can be either the same I use when I login with OWA on a browser:

    myusername@mydomain.local

    or

    MYDOMAIN\myusername.

    Now the log file shows the following:

    2009-03-01 13:20:20 W3SVC1 192.168.88.90 RPC_IN_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6002 443 myusername@mydomain.local 86.154.xxx.xxx MSRPC 200 0 64 0 947
    2009-03-01 13:20:20 W3SVC1 192.168.88.90 RPC_OUT_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6002 443 myusername@mydomain.local 86.154.xxx.xxx MSRPC 200 0 0 601 364
    2009-03-01 13:20:41 W3SVC1 192.168.88.90 RPC_IN_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6004 443 myusername@mydomain.local 86.154.xxx.xxx MSRPC 200 0 64 0 1023
    2009-03-01 13:20:41 W3SVC1 192.168.88.90 RPC_OUT_DATA /rpc/rpcproxy.dll NETBIOSSERVERNAME1.mydomain.local:6004 443 myusername@mydomain.local 86.154.xxx.xxx MSRPC 200 0 0 665 364

    NOTE: after the MSRPC entry, I now have the result code "200 0" which is good.

    I can now roll out other users.

    Paul

    Sunday, March 1, 2009 2:06 PM
  • Well I finally found a fix.  I have had this issue for almost two years now.  Since people started going out and getting 2007 I couldn't make the rpc connection work without bringing the computer into our network and launching outlook and logging in.  Once that was done I was able to turn the user loose. 

    I found this tool  http://www.petri.co.il/software/rpcnofrontend.zip online and it solved the problem today.  2007 clients are able to sign in with no issues at all now.

    Thanks for the suggestions on here.  Can't believe no one had this before and what's more I can't believe Microsoft wouldn't provide this tool themselves.
    • Proposed as answer by techadmin Sunday, May 17, 2009 8:25 PM
    Sunday, May 17, 2009 8:24 PM
  • I've had the same issue with one laptop with Windows 7 and Office 2007, and after testing all the solutions proposed here, the only thing that have worked is connecting it to the same network of the server, create the account and then enable the RPC overt http.
    Tuesday, May 26, 2009 7:26 PM
  •  1/ (exchange) Servers SSL cert installed into the correct Local Computer (not user), `trusted root certification authority` (not personal).
      2/ using the correct mailbox name (not the logon name)
      3/ setting the connection proxy settings to use http for BOTH slow and fast networks.
      4/ (For Outlook 2007 to exchange 2003) enter the username in "DNS.DOMAINUSERNAME" format (rather than NETBIOSDOMAINUSERNAME format)
      5/ (and now we find that) HKCUSoftwareMicrosoftCurrentVersionExplorerUser Shell Foldersappdata *MUST* contain a suitable value.

     6/ port settings in rpc registry 6001  6002  6004


     7/ For the solution, I checked the properties of the "rpc" virtual directory under the Default Web Site in IIS and went to Directory Security and then edited "IP address and domain name restrictions". I removed the current denial rule in there which was effectively only allow local access, and said grant access to all.

    Thankyou .. David Barnes.. it was #7 on this checklist that was breaking my clients laptop..   Fixed it.. IISRESET and all good now...

    Tuesday, July 14, 2009 2:05 PM
  • I have also experienced this issue with Office 2007 & Exchance 2003.  The solution for me involved the Microsoft Article 913843 but required another DWORD to be added under the same RPC sub key (in the registry):

    HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC\

    DWORD Value    DefConnectOpts     with a value of 0 (as per the Microsoft Article)  PLUS:
    DWORD Value    EnableRPCtunnel    with a value of 1

    Hope this helps...

    • Proposed as answer by morrisdb Friday, November 13, 2009 9:25 PM
    Thursday, October 29, 2009 12:34 AM
  • This is a terrible issue and it has been going now for a long time.
    For those who use Exchange server 2003 with a VPN connection, this is how I got it to work:
    (This is not a solution but a work-around that may not be practical for everyone)

    I installed Hamachi (https://secure.logmein.com/products/hamachi2/) on the server and client and got Outlook to authenticate successfully (Finally Outlook doesn't get stuck in a cycle, asking me for a user name and password) . But if I enable the Microsoft VPN, then it goes back into the same issue, I can only use Outlook via Hamachi VPN)

    (I'm using Windows 7 with Outlook 2007 and Exchange Server 2003 via VPN connection)
    • Edited by DubMasta Monday, November 2, 2009 9:51 AM typo
    Monday, November 2, 2009 9:49 AM
  • I have the same issue (Win 7 client with Outlook 2007 failing to RPC/HTTP to Exchange 2003 on SBS 2003 SP2).  Surely there must be thousands of people experiencing this simple failure!  Why do Microsoft not pay some attention to it and offer a fix ASAP!!!!!

    I'm going to have to roll the client back to Outlook 2003 so it works like all the others - Jeez what progress!!!
    Monday, November 9, 2009 7:45 AM
  • OK, I was slamming my head into my desk for weeks figuring this out.

    First, go to www.testexchangeconnectivity.com. Handy tool to determine if you got your stuff right on the server side. One thing that got me was the PRC ValidPorts registry setting: http://technet.microsoft.com/en-us/library/aa998910%28EXCHG.65%29.aspx. Be sure that you use your FQDN for your "Exchange Server" field as seen from *inside* your network (i.e. exhange.yourdomain.local), and add a reference for ValidPorts for your FQDN. Make sure ValidPorts range contains the 6000's (mine is set to 500-7000). If this test doesn't pass, you won't get anywhere. Make sure your SSL certs are up to snuff, etc.

    Second, when configuring Outlook, "Exchange Server" should be the *internal* FQDN of the Exchange Server as seen above, not the *external* FQDN of your RPC proxy. (i.e. exchange.mydomain.local instead of publicrpcproxy.myexternaldomain.com)

    Third (and what really irks me), never click the "Check Names" button. Ever. It seems to cause Outlook to go into "Nope! Not going to work!" mode, completely ignoring your proxy for the rest of the account setup. If you ever click on this button, cancel out of the account setup and restart it. My guess is that this is a hard-core bug in Outlook 2007. Outlook 2003 does not seem to have this problem, as far as I can tell.

    I hope this helps someone out there in I.T. land. This is far more complicated (and in many cases buggy) than it should be. Hopefully, someone can profit from my pain.
    • Proposed as answer by jtwestmo Wednesday, November 11, 2009 2:27 PM
    Wednesday, November 11, 2009 2:10 AM
  • I have read almost this entire post and tried most everyhting there and I can't remeber if I read it here or somewhere else but I can say nothing worked until I made my Exchange 03 server a global catalog server.  I know many people can't do that but I was able to and then poof it started working.

    Just add it to the list of things to try.
    Wednesday, November 11, 2009 2:31 PM
  • I have also experienced this issue with Office 2007 & Exchance 2003.  The solution for me involved the Microsoft Article 913843 but required another DWORD to be added under the same RPC sub key (in the registry):

    HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC\

    DWORD Value    DefConnectOpts     with a value of 0 (as per the Microsoft Article)  PLUS:
    DWORD Value    EnableRPCtunnel    with a value of 1

    Hope this helps...


    COWABUNGAAA!!!! This, after everything I've tried from this thread and many, many more KB articles and suggestions, FINALLY fixed my problem. Thanks a million...!

    My setup:
    -Windows Standard 2003, with Exchange 2003. All roles performed by 1 server (essentially the same as SBS2003, but without the nice wizards to do things for you). Setting it up originally for RPC/HTTP with Outlook 2003 clients was a challenge, but Petri's articles are a huge help.
    -Self signed certificates, imported into computer trusted root certificate store (not user store)
    -Outlook 2003 clients on domain computers connected via RPC no problem.
    -Outlook web access worked for all domain users
    -Outlook 2007 could connect on local lan via TCP/IP but died the instant I enabled Outlook Anywhere.

    I tried everything, every reg key entry I could find. Went over all the permissions on my IIS website folders, deleted and recreated my Outlook profile umpteen times, tried every magical "first click that" or "dont click that" step I could find...nothing...until now...thank you, thank you very much!!!

    One thing to note - in the Outlook Anywhere setup, I have "only connect to proxy servers.." unchecked. If I try to use that option, it won't connect, but repeatedly prompts for the password. No idea why, as I have Outlook 2003 setup using that field with msstd://EXTERNAL_FQDN.

    Also, I'm using NTLM authentication, works fine for me.
    Friday, November 13, 2009 9:49 PM
  • Yes, you can; but why would you
    Big George
    Wednesday, November 25, 2009 11:54 PM
  • I have also experienced this issue with Office 2007 & Exchance 2003.  The solution for me involved the Microsoft Article 913843 but required another DWORD to be added under the same RPC sub key (in the registry):

    HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC\

    DWORD Value    DefConnectOpts     with a value of 0 (as per the Microsoft Article)  PLUS:
    DWORD Value    EnableRPCtunnel    with a value of 1

    Hope this helps...

    I'm using Office 2003, I have no \12.0\Outlook folder in the registry...
    Still having this problem:
    Using windows 7 Professional, Office 2003, Exchange 2003 on SBS 2003 (http connection, basic authentication).

    (I currently using win XP mode in order to work with exchange...)
    Sunday, November 29, 2009 8:35 PM
  • Can anyone else concur if maybe these problems are due to running Outlook 2007 on a Windows 7 - 64 bit client?  The emphasis here is on the 64 bit OS rather than 32 bit OS? 

    Many thanks
    frank
    Monday, November 30, 2009 9:40 PM
  • I was having the same issue as all above.  I fixed the problem in the following manner.  In Windows 7 I went to contol panel then to user accounts.  I then went in to Credentials manager.  I added my mail.companyname.com to generic credentials with my username and password.  I rebooted and all has worked since then.  Hope this helps.
    Thursday, December 3, 2009 6:54 PM
  • For those still struggling with this, I narrowed it down to the fact that an Exchange 2003 update broke the rpc mechanisms, specifically the rpcproxy.dll was corrupted preventing Outlook Anywhere from connecting. Go into Add/Remove programs, Add/Remove Windows Components, Networking Services, uncheck "RPC over HTTP Proxy", click OK and let it finish. Then go back in to the same spot and check it. It will reinstall the rpcproxy.dll.
    Thursday, December 10, 2009 8:50 PM
  • I started having this issue yesterday.  This post was very close to the solution that worked for me.

    Outlook 2007 on both of my XP boxes mysteriously stopped working.  I was getting prompted for username/password over and over again.

    I have a Windows 7 box and a Windows Server 2008 box.  Outlook 2007 worked fine on both using exactly the same HTTP proxy configuration as the XP machines.

    I'm still not sure what caused the problem.  Maybe something in the server certificate changed?

    In the Proxy server configuration, I changed the "Only connect to proxy....." field from:

    msstd:server.domain.com to:

    msstd:*.domain.com

    We must be using what you call a "wildcard certificate."  

    Just as you said, "msstd:server.domain.com" works fine in Windows 7 and Server 2008 (I don't have a Vista box at home to test).

    What I don't understand is how this would suddenly stop working in XP....unless our Exchange admin changed the server cert.

    I spent hours trying the other fixes in this thread to no avail.  Today, I happened across a Microsoft page that talked about troubleshooting HTTP connections to Exchange.


    I discovered the "msstd" mismatch when I used the RpcPing command with the -E switch as referenced on that page.

    We use Basic Authentication, SSL, and Mutual Authentication to connect to the store so I used this syntax:

    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 –B msstd:server_certificate_subject -E

    A word of warning though.  You can't just copy and paste this from the page and drop in your info.  The dashes in front of the switches don't translate correctly into the command line for some reason.  I had to paste the command into Notepad, delete and replace all the dashes, then paste.  

    This is the result that tipped me off:

    RPCPinging proxy server server.domain.com with Echo Request Packet
    Checking IE setting...
    The proxy setting is disabled.
    Sending ping to server
    Response from server received: 200
    The server certificate subject from the RPC proxy (msstd:*.domain.com, XXXXXX blah blah etc etc....) does not match the one (msstd:server.domain.com) specified
    Ping failed.


    Hope this helps someone.



    You can connect with Windows Vista, but can't connect with windows XP?

     

    SAN certificate principal name window XP outlook issue and solution

     

    Environment:

    Exchange 2007, Office 2007

    You got a SAN certificate like this:

    CN=domain.com

    DNS=webmail.domain.com                  (your Outlook Anywhere entry point)

    DNS=autodiscover.domain.com

    DNS=www.domain.com

    DNS=domain.loc

    DNS=webmail.domain.loc

    DNS=autodiscover.domain.loc

    ECT

     

    Outlook client profile configuration:

    Exchange proxy server:

    https://webmail.domain.com

    Connect using SSL only > Only connect to proxy servers....

    msstd:webmail.domain.com

     

    In Windows Vista this will work, but in Windows XP it won't. In windows XP you can't put msstd:webmail.domain.com in your "Only connect to proxy.." field you have to put msstd: domain.com there, even if it points to the void, doesn’t matter really (ignore that space after msstd: its there to avoid a smilly). In Window Vista you can put msstd:webmail.domain.com there. The same probably applies for other versions of windows, office and exchange (haven’t tried this do). This is because webmail.domain.com isn’t your principal name, domain.com is. I got no idea why Vista allows it. I know this is a bit of RTFM and shame on me, but it’s an extremely easy error to make and if you test under Vista first and it works, well then like me you might search everywhere but right in front of you Smile

     

    Edit: Hmm now I think about it, the same may apply to wildcard certificates. Haven't tested that do.


    Thursday, December 24, 2009 12:28 AM
  • I also have had to deal with systems balking at connecting to Exchange.  Here is what I did to fix the problem.

    1. Edit the host file in Windows/System32/Drivers/etc
    add the IP address of the server and the FQDN  e.g.  192.168.1.1   mailbox.bizsrv.local
    do this for ALL servers in the domain.

    2. Edit the lmhosts file, same location
    add the IP and NetBios Name  e.g.    192.168.1.1     mailbox     #pre

    You may have to give the active user account full permissions to be able to save the files.
    Also use TAB between the values when editing the files.  192.168.1.1(TAB)mailbox.bizsrv.local

    After doing this Outlook connects and syncs the local copy.

    I see this happen more on 64bit system than 32bit.

    Hope this helps.

    Friday, January 22, 2010 7:58 PM
  • Finally got this Windows 7/Outlook 2007 machine straightened out.  I bungled the initial profile setup and then couldn't log onto this particular Exchange 2007 server from this PC no matter what.  I could RPC to other Exchange servers no problem but this one wouldn't take my username/password, any username/password, whether I used NETBIOS name or FQDN.
    My success came when I changed the "Logon network security" on the Security tab from Negotiate Authentication to Password Authentication (NTLM) AND then repeatedly typed the FQDN\username (server.domain.local\username) into the password prompt.  Outlook started to display the desktop but then said it couldn't open the information store (further than I had gotten before).  I tried Outlook again and repeated my FQDN\username & password input (twice) and Outlook finally opened.
    I've since changed the Logon Network Security on the Security tab back to Negotiate Authentication and it's still working.  It prompted me once for the username/password and I simply supplied the password with the username prefilled in with NETBIOS_NAME\username and it was happy.

    In my case, I believe something was being remembered somewhere to do with security credentials, despite removing/recreating the profile, as it affected every account but only on this particular Exchange server.
    Thursday, February 11, 2010 7:45 PM
  • I just had the same thing happen.  Win7 machine with outlook 2007 connecting to an exchange 2003 server.  There was a VPN involved.  I was able to resolve this in a similar manner, trying FQDN\username and also server.local\username.  These didn't work but after about 10 attempts of various combinations i tried domain\username and it then finally worked.  

    I was able to identify it as an authentication issue because when i tried logging in with an incorrect password, it would prompt me again.  If i used the correct password, it would not prompt me, but it would disappear and then say disconnected and not reappear.  

    Hope this may help someone down the road. 
    Thursday, February 25, 2010 10:07 PM
  • Are Any of the "oldies but goodies" around? (Qmacker? Dave, ?) ever get a REAL Resolution? I too have been working this issue:
    New Dell Vostro With Win XP pro, delivered with a demo office installation. This computer connected with Exchange 2003, all was good..UNTIL...User has a reatail upgrde of office 07 license that is coming off the computer being replaced. Microsoft had me uninstall the demo, and download a copy of office from them, and allowed me to register the downloaded verrsion of office. Technician gets off the phone, time to test. Outlook cannot connect to exchange server. Connection to exchange server unavailable, Yada, Yada outlook must login to create the account...

    Since then, a month ago, I have worked this problem from the ground (hardware) up (every Fix above, PLUS Network cards, drivers etc. and There ar a few other referenced fixes on petri...

    NO Luck... and after the removal (07), install-03, upgrade, (07), perform all tweaks above, and then some, rinse, and repeat all with a straight up 0ffice 07 enterprise, tweaks above, and more that were found in between and now machine is potentially unstable.

    Did anyone find a stable fix to the specific issue of the trial copy upgrade, issue?  

     PS Qmacker you were on to something..This user account works golden, on 4 different outlook installs, 2K3 Server, Windows XP PRo, Vista, and 7. But NO account will work from this one machine..
    Monday, March 1, 2010 4:58 AM
  • Hi ifitwaseasy

    I seem to have resolved all of the instances I have run accross either with:

    A) Use of FQDN\username 
      See: http://bitsolve.spaces.live.com/blog/cns!D0597DCC1B3A70EF!289.entry

    B) missing registry values
      See: http://bitsolve.spaces.live.com/blog/cns!D0597DCC1B3A70EF!316.entry

    C) (backup data first) and delete the user profile, logon as user (creating clean profile) connect outlook using either A) or B) fixes above (Or even both)..

    Only in one case did I have to:
    D) re-install windows..

    Hope this helps

    David (nobby) Barnes

    Tuesday, March 30, 2010 7:47 PM
  • JRod,

    When I started this topic months ago, the problem I was having really had nothing to do with Outlook 07 connecting to Exchange 03, as I learned. I've had much experience setting up private certificates, but whatever reason, this time I just couldn't get it to work. I paid the $20 for a Godaddy cert, and since that day I have vowed to never try and use a private cert again. The Godaddy certs are so cheap, and they work every single time.

    If you're still having trouble with this, reply to this post with the things you've tried and I'll try and help you.


    Jess

    Thank you Jess....

     

    I too will never again use a private certificates on an exchange server. I tried for hours to make this work on two computers with Win XP Pro - Outlook 2007 - Exchange 2003 to no avail. On outlook 2003 no problems but on 2007 no way did it work.... 

    I got myself a certificate from Go Daddy and wola it worked on the first try. NO MORE PRIVATE CERTIFICATES FOR ME!!! 

    Saturday, April 3, 2010 7:02 PM
  • Here is the ironic part. I called my customer to let him know I found a solution and to suggest to him we get a certificate from Go Daddy for his exchange server and he tells me that it is working now for him.

    His setup is the same Win XP Pro - Outlook 2007 - Exchange 2003

    It did not work when I first tried it (on two different occasions). What seems to have done the trick is I setup it up and the user went back to the office to authenticate his notebook on the network and when he took it back home it worked. But I have no way to verify if that is actually the solutions...

    Regardless I'm still sticking to my rule...NO MORE PRIVATE CERTIFICATES FOR ME!!! 


    Saturday, April 3, 2010 7:56 PM
  • The following link worked for me when Outlook 2007 was not connecting with Exchange 2003 over the VPN tunnel. The reason was when VPN link is established, the default gateway is not assigned. So, exchange can not authorize the link. following registry entry forces outlook the ignore the gateway security and use the default gateway.

     

    http://support.microsoft.com/kb/913843/en-us

     

    See if helps.

     

    Good work guys.

    Friday, August 6, 2010 2:27 PM
  • Hi

    if you are using windows 7 or vista install first certificate and then run outlook 2007.  Make that address trusted site and install certificate in trusted root certificate and make sure you have port 443 open in your router and hardware file if you are using.  I installed too many servers little diferent with sbs2003 and sbs2008 no problem with exchange 2003 and exchange 2007.

    if any more info please be posted.

     

    thanks


    Naeem Bhatti MCITP EA, MCITP, MCTS Exchange 2007 MCSE security,MCSE AD, MCSE in Messaging, MCDST SBS2003 and SBS2008 Specialist
    • Proposed as answer by nbhatti Tuesday, August 17, 2010 10:19 AM
    Tuesday, August 17, 2010 10:12 AM
  • I've just spent several hours on this issue as well. We have SBS 2003 for the server and Outlook 2007 on Windows 7 for clients. We are using a self signed certificate made by the Internet Connection Wizzard in SBS 2003.

    I opened MAIL in Control Panel

    Selected E-mail Accounts

    Selected Change for the Exchange Server.

    Clicked on more settings button

    Clicked on Connection Tab

    Clicked on Exchange Proxy Settings button

    Change the Authentication drop down box to "Basic Authentication"

    Closed and saved all windows as I closed the wizzard.

    At this point it worked and our clients could connect. Maybe this process will work for someone else. Good luck with this as everything I could find on the internet didn't help me and I stumbled upon this solution out of desperation.

     

    Thursday, October 14, 2010 7:00 AM
  • I saw this forum and thought it may apply to your problem. Sorry for the 3 year nightmare.

    http://social.technet.microsoft.com/Forums/en-US/exchangesvrsecuremessaging/thread/f27e727a-a594-411b-937f-daf7abd8bc57 >>>Sucromatic

    PS Please don't get mad at me if it doesn't help.


    SUCROMATIC
    Friday, November 12, 2010 4:06 AM
  • I hope my experience with all of this will be of some help to all the others struggling with this issue, so here goes.

    I’m assuming the following:

    ·         You are using Outlook 2003 or Outlook 2007.

    ·         You are attempting to connect to Exchange Server 2003. I’ve not got this to work with Exchange Server 2007 yet.

    ·         You do not have a front end server, if you do, you’ll have to adapt this information to your situation, as my experience is only with a single server running all components of Exchange Server 2003.

    ·         You do not have a VPN connection to the network the Exchange Server is on, as the whole point of RPC over HTTP is to allow users who can authenticate and are on the Internet anywhere in the world to connect to their Exchange mailbox.

    ·         You have installed the RPC over HTTP Windows component.

    ·         You can connect to OWA by using https://URL/Exchange, noting that it is https not just http.

    ·         When connected to OWA and you view the certificate, what you see in the “Issued to:” field must be the server’s public URL that you will use below, whether it is a publicly signed or a privately signed certificate, and this is the URL you will enter as the RPC Proxy for Exchange.

    ·         When you finally have everything configured properly and are adding the account in Outlook and click on the “Check Name” button and are prompted to authenticate, use the domainname\username format, as that is the only way it will work for me.

    ·         You can perform a successful RPCPing to the server while out on the Internet using the command as explained below:

    RPCPing –t ncacn_http –s fqdnServerName –o RpcProxy=PublicServerURL –P “UserName,NetbiosDomainName,*” –I “UserName,NetbiosDomainName,*” –H 1 –u 10 –a connect –F 3 –v 3 –E –R none

    You will be prompted for the UserName’s password twice.

    If successful, you will see the following:

    RPCPing vX.XX. Copyright Blah Blah Blah

    OS Version is: Blah Blah Blah

    Response from server received: 200

    Ping successfully completed in X ms

     

    You may be able to get away with using the public URL or any other name in the fqdnServerName field that resolves to the WAN IP address of the Exchange Server, either using DNS or your hosts file, for the RPCPing to succeed, but you must use the real name of your Exchange server when you specify the server name while adding the account in Outlook, and I prefer to use the server’s true fqdn, just as you see it by full computer name on the Computer Name tab on the System Properties window.

     

    This presents a dilemma if you have a laptop that is used both in the office and out of the office, as the fqdn of the server must resolve to the public IP address of the Exchange Server when on the Internet, and the private IP address of the server when on the LAN. So, what is the dilemma?  It’s what should the fqdn of your server really be to make this work. 

     

    If you use something in the format of servername.domain.local, you will be able to make it work if the user is comfortable modifying their hosts file as they transition in and out of the office, and if they are, then you can get away with just using the server’s name without specifying the domain name, but using a fgdn that DNS can provide name resolution for, like servername.domain.com, or better yet, servername.ou.domain.com, as I don’t like to use my Internet domain name as my Intranet domain name, will provide the greatest flexibility.

    Don't forget to review the following link as well:

    http://www.petri.co.il/how-can-i-configure-rpc-over-https-on-exchange-2003-single-server-scenario.htm

     

    • Proposed as answer by iamgeorgestark Thursday, February 17, 2011 2:57 PM
    Thursday, January 27, 2011 6:32 AM
  • Guys, My two penneth,

     

    We had the same issue SAN certy from digicert, Outlook 2003 client no issue outlook 2007 no connecting and continually prompting form user nam or passwor.

     

    Are setting were:

    URL to connect:     https://ukwebmail.domain.com

    Connect using ssl: msstd:ukwebmail.domain.com

     

    now even though we had "Only connect to proxy servers that have this principle name..." unticked i didnt work

     

    the principle name on the SAN was webmail.domain.com, changed the msstd to this and it worked, ukwebmail.domain.com was in the cert as well as others.

     

    Something not qiute right with Outlook 2007, outlook 2010 worked fine.

     

    George

    Thursday, February 17, 2011 3:03 PM
  • This worked for me, it kept prompting for the login each time outlook open so I tried turning it off and it continues to work now - seems once the trust is established all is good
    Monday, March 21, 2011 11:33 PM
  • I hope this may help someone, I've realised that its all tied up with whatever proxy server you have specified in Internet Explorer. I removed the Proxy settings from IE and it now works fine.
    Thursday, June 9, 2011 7:35 PM
  • our solution was that IIS rpc directory was not configured properly. we had selected run scripts only and the correct setting is programs and scripts. we did this all with a self signed ssl cert runs fine with our CA trusted on domain.
    Quote by andhey "hmm ill try it later, i accidentally deleted all my tv shows when trying to delete a word document lmao"
    Thursday, August 11, 2011 2:19 PM
  • finally i've got it to work by folowing those steps 

    !- got to your domain controller >>administrative tools >>Certificate Authority

    2- right click on your domain name on the left panel >> Proprieties >> General Tab >> View Certificate

    3- new window will appear >> Details >> Copy To file

    4- install this certificate on the Client machine and i hope it will work as it did for me

     


    CCNA, MCSE, MCITP
    Tuesday, September 13, 2011 10:00 PM
  • I am looking in to this problem some days now, not only on Outlook 2003 but on 2007 and 2010 as well. I have followed all the needed procedures found around the web but nothing. Outlook 2007 keeps asking for username/pass without going anywhere. The run command outlook.exe /rpcdiag shows that there is no active or actually working connection.

    My solution came after doing the following:

    At first on the client side:

    Added the following on registry  key [HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\RPC]

    12.0/13.0 for prior Outlook versions

    (if no rpc key, then simply create it, right click on Outlook>new key)

     

    "DefConnectOpts"=dword:00000000 (as colleagues mention above)

    Also add the following under RPC as well

    "ConnectTimeout"=dword value with hex value 000493e0

    "RFRTimeout"=dword value with hex value 000493e0

    Secondly on the server

    On http://www.petri.co.il/how-can-i-configure-rpc-over-https-on-exchange-2003-single-server-scenario.htm you will find the best way to resolve it....but as we ITs are on hurry all the time, we don't usually see what "exists" right in front of our eyes.
    Download the tool called RPCNoFrontEnd (19kb) mentioned on the page (mid). Execute after putting your external fqdn. This tool will make all the necessary registry changes needed on the server part and till now I have not found elsewhere. God bless the guy who wrote it, Harry Bates.
    Restart your server in order the registry changes to have effect.
    Test your Outlook client Exchange connection through RPC/HTTPs (/rpcdiag if you want). It will take a while in the first time but I worked for me.
    Hope this helps...I'm going to sleep now, cause I have a tough day tomorrow.

     


    • Edited by Chrysostomos Monday, October 17, 2011 10:31 PM
    • Proposed as answer by Chrysostomos Tuesday, October 18, 2011 6:59 AM
    Monday, October 17, 2011 10:22 PM
  • Found this and completely solved all my problems.

    http://www.outlookexchange.com/articles/HenrikWalther/RPC_over_HTTP.asp

    On your RPC proxy launch regedit

    HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy

    Here you need to change the value of the ValidPorts key, the values should be entered in the below format:

    ExchangeServer:593; ExchangeServerFQDN:593; ExchangeServer:6001-6002; ExchangeServerFQDN:6001-6002; ExchangeServer:6004; ExchangeServerFQDN:6004; GlobalCatalogServer:593; GlobalCatalogServerFQDN:593; GlobalCatalogServer:6004; GlobalCatalogServerFQDN:6004

    This means if your Exchange server is named Exchange01 and your Global Catalog server is called GlobalCatalog01 and both are members of the AD domain privatedomain.com , it should look like:

    Exchange01:593; Exchange01.privatedomain.com:593; Exchange01:6001-6002; Exchange01.privatedomain.com:6001-6002; Exchange01:6004; Exchange01.privatedomain.com:6004; GlobalCatalog01:593; GlobalCatalog01.privatedomain.com:593; GlobalCatalog01:6004; GlobalCatalog01.privatedomain.com:6004


    Now we need to logon to the Global Catalog server (which would be the Domain Controller), here we need to add a string to the registry as well, so navigate to:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

    - Then click Edit in the menu > New then click Multi-String Value
    - Name it NSPI interface protocol sequences
    - Right-click the NSPI interface protocol sequences multi-string value, and then click Modify
    - Type ncacn_http:6004 in the value box

    Now restart the Global Catalog Server.

     

     

     


    CP
    Tuesday, October 25, 2011 9:55 AM