Exchange 2K3 - RPC over HTTP

Hey guys,

I've been working on setting up RPC over HTTP off an on for about a month and I just can't seem to get it to work? Does anyone have any experience in this sort of thing?

I've gone through all the steps here How to Deploy RPC over HTTP for the First Time on Exchange Server 2003 SP1 (Front-End/Back-End Scenario) but have had no luck. We do have a Front-End/Back-End setup and it appears that everything starts out correctly but it just fails.

Outlook /rpcdiag shows it connecting to the Front-End server and then it starts to reference a Global Catalog but immediately fails. It never even shows whether it's connecting via TCP/IP or HTTP.

The one thing to note is before I became the Administrator at my company, the former admin really screwed with the applications and some things just don't work anymore. It's possible that I just need to reset something but I'm not sure what it is, any ideas?

I'm at the point where I'll probably just bring in a consultant if I can't get this stinking thing working. :)
1) CCNP Goal: by August 2012

Comments

  • blargoeblargoe Member Posts: 4,174 ■■■■■■■■■□
    Is the authentication on the Outlook client set correctly (Basic vs. NTLM)?
    IT guy since 12/00

    Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
    Working on: RHCE/Ansible
    Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
  • genXrcistgenXrcist Member Posts: 531
    It is set for Basic Authentication on the FE server but your question made me wonder if it was setup on the BE... it wasn't. I changed the RPC virtual directory to Basic Authentication (from Anon & Integrated), rran iisreset............still no go.

    RPCDiag shows it connecting to my internal, BE mail server with a 'Referral' Type and then it switches to a GC with a 'Directory' type and immediately thereafter it goes to Status 'Disconnected.'

    Ugh.

    Oh, and yes it's set correctly on the Client as Basic Authentication. :)
    1) CCNP Goal: by August 2012
  • GrayhenTorGrayhenTor Member Posts: 43 ■■□□□□□□□□
    Sounds like it maybe a problem with the servers/ports listed on the FE server's HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy key. Or maybe HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters on the DC/GC is set wrong. Or maybe one of the required ports isn't open between the FE and the BE or the FE and the GC...
  • genXrcistgenXrcist Member Posts: 531
    GrayhenTor wrote: »
    Sounds like it maybe a problem with the servers/ports listed on the FE server's HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy key. Or maybe HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters on the DC/GC is set wrong. Or maybe one of the required ports isn't open between the FE and the BE or the FE and the GC...

    Thanks for the reply Grayhentor but unfortunately, those keys are correct. When you say the required ports between the FE & the BE, what ports might those be?
    1) CCNP Goal: by August 2012
  • astorrsastorrs Member Posts: 3,139 ■■■■■■□□□□
    genXrcist wrote: »
    what ports might those be?
    tcp/6001 (Information Store), tcp/6002 (Directory Referral) and tcp/6004 (DSProxy/NSPI)
  • genXrcistgenXrcist Member Posts: 531
    astorrs wrote: »
    tcp/6001 (Information Store), tcp/6002 (Directory Referral) and tcp/6004 (DSProxy/NSPI)

    These are the ports the BE server needs open, correct? Neither of the FE/BE servers are DC's so if I understood the articles correctly, the FE server doesn't require any sort of Registry editing, simply making it a FE server opens the correct ports.

    I don't think the issue lies between the FE/BE servers because the BE server prompts me to authenticate. The failure occurs when the 'Referral' process begins. This would lead me to believe port 6002 needs to be opened on the GC's but I've found no documenation that states this.

    Thoughts?
    1) CCNP Goal: by August 2012
  • genXrcistgenXrcist Member Posts: 531
    I was wrong, the issue did lie between the BE & the FE... but not the way I thought. I got tired of the problem so I just called a local 3rd party Support helpdesk and this is what we discovered.

    When attempting to go to https://localhost/rpc we got 401.1 errors, which deals with invalid credentials. We should have gotten 403 errors. Anyway, after looking at the permissions of the FE RPC virtual directory on a working Exchange server w/RPCoverHTTP we discovered that we needed the Scripts & Executables option selected, not just the Scripts option. After making this change, voila. HTTPS connection were made when running outlook /rpcdiag!

    Yet another piece of my former manager's legacy left behind. He made changes in IIS like this all the time and never changed them back nor documented the changes he made.

    UGH!

    Thanks for the help guys!
    1) CCNP Goal: by August 2012
  • GrayhenTorGrayhenTor Member Posts: 43 ■■□□□□□□□□
    Great that you got it solved! I'd never have thought of checking that setting in IIS. I don't remember it being mentioned in the Technet link either .. but then I was half a sleep when I read through that.

    Hope that you don't find too many more gremlins left by your predecessor!
Sign In or Register to comment.