Rich,

Just so you know you're not alone, I'm having the same problem. Actually
opened a paid MS support ticket. Eventually traced the problem to Google
desktop indexing e-mail. At least we thought so. We had all our remote
clients disable this and the problem was resolved... for about three weeks
and has resurfaced recently.

I'll be checking into the things Neo discussed here on our infrastructure
and will post what I fine.

Ben

"Rich Bashaw" wrote:

Thanks Neo. It definitly seems to be directory related and only for some
clients. If you can confirm where that reg entry goes, I will try that next.

Thanks,

Rich

"neo [mvp outlook]" wrote:

I don't have any experience with NLB clusters when it comes to FEs, but I
think the change only has to be done on the BEs. I'm trying to get
clarification from the exchange mvps just to make sure that i give you good
info.

/neo


"Rich Bashaw" wrote in message
...
It did contain DC/GC reference. I deleted it and relaunched Outlook. Same
problem and it recreated the same registry key.

I did have my Outlook configured to use HTTP on a fast connection and I
even
went further and added the DisableRpcTcpFallback registry kety to force it
to
use HTTP and it failed to connect at all.

Internal DNS uses the same FQDN so that it matches the SSL cert, it just
resolves to a private IP rather than a public one. As an experiment, I
added
a HOSTS file entry for the external IP of the RPCProxy server, and it
tried
harder to connect. It gets a Mail and a Referal with HTTPS and then hangs.

Maybe I should try the RFR reg key. Do I do that on the RPC PRoxy server
only or all backend servers as well?

We have 2 NLB front end exchange servers (RPCPRoxy is the Virtual IP of
this
NLB cluster) and about 5 backend servers the main one is a Windows
Active/Passive cluster.

"neo [mvp outlook]" wrote:

Double click on it and see if it contains a reference to a DC/GC. Not
sure
how big your site is, but I'm half tempted to point you at
http://support.microsoft.com/default...282446&sd=RMVP
and
say set the "No RFR Service" registry value. This will cause the
Exchange
200x boxes to proxy all GC calls. (If you do set it, restart exchange
services, and then delete the value you/i have on the client workstation.
once that is done, outlook 2003's rpc diagnostic dialog should show
exchange
handling directory calls.)

The default connection methodology for Outlook 2003 when RPC/HTTP is
configured:
Fast (broadband or better) - TCP/IP then HTTP
Slow (128k or slower) - HTTP then TCP/IP

A user can check the box in the proxy settings where Outlook will try
HTTP
first on a fast connection. If yours is this way, then there are some
things one could do to stop the connection. For example:

1) The RPCProxy folder in IIS is configured to prohibit connections from
internal IP addresses

2) Filtering on the VPN connection

3) Different name resolution strategy for internal vs. external users
(e.g.
example, lets say the exchange proxy server's external dns address is
outlook.contoso.com. internally, this entry might not exist.)


"Rich Bashaw" wrote in message
...
I have a 001f662a, but that is all.

I have noticed another difference. When I connect from home over the
Internet, every thing works fine. When I connect my VPN and then
beccome
part
of the same subnet as the mail server, it fails for RPC over HTTP and
defaults to TCP/IP. Is there a reason it would not work when I am on
the
same
subnet?

"neo [mvp outlook]" wrote:

Assuming that there are no issues with web server certificate for the
rpcproxy folder in IIS (e.g. hitting it with the web browser does not
generate the security prompt about the certificate), the only thing
that
comes to my mind is where Outlook is trying to authenticate to a GC
over
RPC/HTTPS.

As of SP1/2 for Exchange 2003, GCs are no longer advertised via
DSProxy
for
RPC/HTTP clients. If you can, see if one of your customers is willing
to
open regedit and motor to:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows
Messaging
Subsystem\Profiles\profile\dca740c8c042101ab4b90 8002b2fe182

If the string value 001e6602 exists, delete it.

By the way, when you guys tried a new mail profile. Did you delete
the
existing mail profile and then recreate it with the same name or
create a
new one and then delete the old?

/neo

PS - the value should be removed while Outlook is closed.


"Rich Bashaw" wrote in message
...
We have RPC over HTTP enable and it is working for some users.
Others
cannot
connect at all. We have tried new profiles to no avail. The only
thing
that
seems to work is a fresh install of Office 2003 on the machine. And
sometimes
that doesn't work either. Sometimes you need to reinstall the OS and
Office.
We have a lot of users offsite and we would like to avoid having to
reinstall
for all of them. They all have the correct versions of Office and
Windows.

These offsite user used to be part of a different domain. We
migrated
the
office to a new exchange server and a new user account. They were
previously
connected to a SBS server and using RPC over HTTP.

What I would like to know is if there are certain regisrty settings
that I
can check and fix rather than doing a complete reinstall.

Thanks,

Rich

Hi Guys,

Definitely not alone. This is my second main bout with RPC/HTTPS. The
first was a nightmare, and it was server side, this latest go is client
side. RPC for Outlook drives me nuts, but it is too useful to be
without.

Anyway: newly installed WinXP SP2. Installed from original disc,
however, and put Office 2003 in before update to XP SP2. I think this
may have caused some change to the Offic registry keys. I did notice
some registry inconsistencies on my installation when going through the
google help threads. So, I will blow it away again, install SP2 before
office, and see if that fixes my problem. If it does, I will just add
that to our procedures manual here and be done with it.

Please post you answers if you find them.

Andy