Here is the question and I appreciate your help in advance.


We have a client that has a windows domain with a .local fqdn, lets call it
test.local.
The exchange server name is exchange1, which gives us a fqdn for the
exchange server of exchange1.test.local.
We have setup RPC over HTTP, with a SSL certificate and it works. If we
setup an outlook client on the network to use RPC over HTTP it works ok (on
the same LAN as the server). We ran outlook /rpcdiag, and found that the
client is communicating with the server with RPC over HTTP. That works ok.
Now if we have an Outlook Client that resides outside of the LAN, somewhere
else on the internet, in order to make RPC over HTTP work, we are required
to use a Host File. The host file will contain an entry that points the
address exchange1.test.local to the external address of the firewall (which
routes SSL to the exchange server). That works fine.
The question is this,
Laptops that travel back and forth between the office and out off the
office, cannot use this configuration. If I do not use a host file as
described about, the Outlook Client will work inside the office, but will
not work from outside the office. If I use the host file described above,
the outlook client will work when outside of the office, but not from within
the office.
The problem is clear, the Laptop cannot determine the IP address for
exchange1.test.local when outside of the office, and the host file is not
present. When the host file is present, and the computer is plugged is on
the LAN, it tries to connect to the wrong IP address.
In the outlook 2003 configuration, there are two locations to place the
computer name of the exchange server. The first is under Exchange Server
Settings, and the second location would be under Exchange Proxy Settings.
It seems that we need to use the FQDN of the exchange server
(exchange1.test.local) in order to connect to the exchange server properly.
Do you know of a way to get arround this problem?

Assuming this is a single server site and the SSL certificate shows issued
to exchange1.test.local, then I think your stuck. Ideally if issuing the
certificate from your own CA, the SSL certificate should be issued to the
FQDN on how the server will be accessed from the internet. This should
eliminate the host file because the only thing that Outlook will fail the
connection on is when "Issued To:" line on the SSL certificate doesn't match
what is listed in the Exchange proxy settings on the client.


"Stephen Bausch" Stephen wrote in message
...
Here is the question and I appreciate your help in advance.


We have a client that has a windows domain with a .local fqdn, lets call
it
test.local.
The exchange server name is exchange1, which gives us a fqdn for the
exchange server of exchange1.test.local.
We have setup RPC over HTTP, with a SSL certificate and it works. If we
setup an outlook client on the network to use RPC over HTTP it works ok
(on
the same LAN as the server). We ran outlook /rpcdiag, and found that the
client is communicating with the server with RPC over HTTP. That works
ok.
Now if we have an Outlook Client that resides outside of the LAN,
somewhere
else on the internet, in order to make RPC over HTTP work, we are required
to use a Host File. The host file will contain an entry that points the
address exchange1.test.local to the external address of the firewall
(which
routes SSL to the exchange server). That works fine.
The question is this,
Laptops that travel back and forth between the office and out off the
office, cannot use this configuration. If I do not use a host file as
described about, the Outlook Client will work inside the office, but will
not work from outside the office. If I use the host file described above,
the outlook client will work when outside of the office, but not from
within
the office.
The problem is clear, the Laptop cannot determine the IP address for
exchange1.test.local when outside of the office, and the host file is not
present. When the host file is present, and the computer is plugged is on
the LAN, it tries to connect to the wrong IP address.
In the outlook 2003 configuration, there are two locations to place the
computer name of the exchange server. The first is under Exchange Server
Settings, and the second location would be under Exchange Proxy Settings.
It seems that we need to use the FQDN of the exchange server
(exchange1.test.local) in order to connect to the exchange server
properly.
Do you know of a way to get arround this problem?

Neo,
Thanks for the response. The problem here is not really with the
certificate. I can get a certificate with a valid FQDN for the server, and I
can get that certificate installed on the laptop. The problem is in the
outlook account settings, specifically in the exchange server settings for a
profile. When I specify an exchange server name, and then a user name,
outlook goes out and connects to the exchange server. When it connects, it
changes the name of the exchange server in that box to exchange1.test.local.
This exchange server name will keep switching back to that name, even if I
type in a different FQDN. So that is where we are stuck. When then laptop
leaves the office, and they do not have a hosts file, they can no longer find
the server exchange1.test.local. I can set the FQDN of the SSL proxy server
for RPC over HTTP, to whaterver I want, so the problem is not really there,
rather the problem exists in the outlook profile config of the exchange
server.

"neo [mvp outlook]" wrote:

Assuming this is a single server site and the SSL certificate shows issued
to exchange1.test.local, then I think your stuck. Ideally if issuing the
certificate from your own CA, the SSL certificate should be issued to the
FQDN on how the server will be accessed from the internet. This should
eliminate the host file because the only thing that Outlook will fail the
connection on is when "Issued To:" line on the SSL certificate doesn't match
what is listed in the Exchange proxy settings on the client.


"Stephen Bausch" Stephen wrote in message
...
Here is the question and I appreciate your help in advance.


We have a client that has a windows domain with a .local fqdn, lets call
it
test.local.
The exchange server name is exchange1, which gives us a fqdn for the
exchange server of exchange1.test.local.
We have setup RPC over HTTP, with a SSL certificate and it works. If we
setup an outlook client on the network to use RPC over HTTP it works ok
(on
the same LAN as the server). We ran outlook /rpcdiag, and found that the
client is communicating with the server with RPC over HTTP. That works
ok.
Now if we have an Outlook Client that resides outside of the LAN,
somewhere
else on the internet, in order to make RPC over HTTP work, we are required
to use a Host File. The host file will contain an entry that points the
address exchange1.test.local to the external address of the firewall
(which
routes SSL to the exchange server). That works fine.
The question is this,
Laptops that travel back and forth between the office and out off the
office, cannot use this configuration. If I do not use a host file as
described about, the Outlook Client will work inside the office, but will
not work from outside the office. If I use the host file described above,
the outlook client will work when outside of the office, but not from
within
the office.
The problem is clear, the Laptop cannot determine the IP address for
exchange1.test.local when outside of the office, and the host file is not
present. When the host file is present, and the computer is plugged is on
the LAN, it tries to connect to the wrong IP address.
In the outlook 2003 configuration, there are two locations to place the
computer name of the exchange server. The first is under Exchange Server
Settings, and the second location would be under Exchange Proxy Settings.
It seems that we need to use the FQDN of the exchange server
(exchange1.test.local) in order to connect to the exchange server
properly.
Do you know of a way to get arround this problem?

That is expected behavior. I would have to verify this, but as far as I
know, the exchange server name does not have to resolve from an internet
location when connecting via rpc/https. The reason for this is that the
request just gets wrapped into a HTTPS request. I believe it is the rpc
proxy service that unwraps its and does the work of resolving the private
name and getting the info. To give you an idea of where I'm going so it
makes more sense...

1) Physical name of Exchange server is exchange1.test.local
2) Since this is a single server site, exchange1.test.local is also the rpc
proxy server
3) Issue a web server certificate to exchange1.test.local. However make
sure that when requesting that certificate you specify the fqdn of how it
would be access from the internet. For example, from the internet, you might
decide that users access https services on exchange1 by typing
https://exchange1.mypublicdomainname.com, therefore the certificate would be
issued to exchange1.mypublicdomainname.com.

Once the laptop has the signing CA certificate installed, then a profile can
be created. The exchange server name should be exchange1.test.local. The
exchange proxy server name should be exchange1.mypublicdomainname.com. You
should not have to add anything to hosts or lmhosts file for
exchange1.test.local.


/neo

PS - By the way, since I don't know if you are configuring Outlook 2003 to
use rpc/https on fast connections as well as slow, I will warn you that if
Outlook 2003 tries an RPC connection first, it could take up to 2 minutes
before it fails over and tries a RPC/HTTPS connection.

"Stephen Bausch" wrote in message
...
Neo,
Thanks for the response. The problem here is not really with the
certificate. I can get a certificate with a valid FQDN for the server,
and I
can get that certificate installed on the laptop. The problem is in the
outlook account settings, specifically in the exchange server settings for
a
profile. When I specify an exchange server name, and then a user name,
outlook goes out and connects to the exchange server. When it connects,
it
changes the name of the exchange server in that box to
exchange1.test.local.
This exchange server name will keep switching back to that name, even if I
type in a different FQDN. So that is where we are stuck. When then
laptop
leaves the office, and they do not have a hosts file, they can no longer
find
the server exchange1.test.local. I can set the FQDN of the SSL proxy
server
for RPC over HTTP, to whaterver I want, so the problem is not really
there,
rather the problem exists in the outlook profile config of the exchange
server.

"neo [mvp outlook]" wrote:

Assuming this is a single server site and the SSL certificate shows
issued
to exchange1.test.local, then I think your stuck. Ideally if issuing the
certificate from your own CA, the SSL certificate should be issued to the
FQDN on how the server will be accessed from the internet. This should
eliminate the host file because the only thing that Outlook will fail the
connection on is when "Issued To:" line on the SSL certificate doesn't
match
what is listed in the Exchange proxy settings on the client.


"Stephen Bausch" Stephen wrote in
message
...
Here is the question and I appreciate your help in advance.


We have a client that has a windows domain with a .local fqdn, lets
call
it
test.local.
The exchange server name is exchange1, which gives us a fqdn for the
exchange server of exchange1.test.local.
We have setup RPC over HTTP, with a SSL certificate and it works. If
we
setup an outlook client on the network to use RPC over HTTP it works ok
(on
the same LAN as the server). We ran outlook /rpcdiag, and found that
the
client is communicating with the server with RPC over HTTP. That works
ok.
Now if we have an Outlook Client that resides outside of the LAN,
somewhere
else on the internet, in order to make RPC over HTTP work, we are
required
to use a Host File. The host file will contain an entry that points
the
address exchange1.test.local to the external address of the firewall
(which
routes SSL to the exchange server). That works fine.
The question is this,
Laptops that travel back and forth between the office and out off
the
office, cannot use this configuration. If I do not use a host file as
described about, the Outlook Client will work inside the office, but
will
not work from outside the office. If I use the host file described
above,
the outlook client will work when outside of the office, but not from
within
the office.
The problem is clear, the Laptop cannot determine the IP address for
exchange1.test.local when outside of the office, and the host file is
not
present. When the host file is present, and the computer is plugged is
on
the LAN, it tries to connect to the wrong IP address.
In the outlook 2003 configuration, there are two locations to place
the
computer name of the exchange server. The first is under Exchange
Server
Settings, and the second location would be under Exchange Proxy
Settings.
It seems that we need to use the FQDN of the exchange server
(exchange1.test.local) in order to connect to the exchange server
properly.
Do you know of a way to get arround this problem?

You are absolutely right. I don't know what I was thinking. Thanks,

"neo [mvp outlook]" wrote:

That is expected behavior. I would have to verify this, but as far as I
know, the exchange server name does not have to resolve from an internet
location when connecting via rpc/https. The reason for this is that the
request just gets wrapped into a HTTPS request. I believe it is the rpc
proxy service that unwraps its and does the work of resolving the private
name and getting the info. To give you an idea of where I'm going so it
makes more sense...

1) Physical name of Exchange server is exchange1.test.local
2) Since this is a single server site, exchange1.test.local is also the rpc
proxy server
3) Issue a web server certificate to exchange1.test.local. However make
sure that when requesting that certificate you specify the fqdn of how it
would be access from the internet. For example, from the internet, you might
decide that users access https services on exchange1 by typing
https://exchange1.mypublicdomainname.com, therefore the certificate would be
issued to exchange1.mypublicdomainname.com.

Once the laptop has the signing CA certificate installed, then a profile can
be created. The exchange server name should be exchange1.test.local. The
exchange proxy server name should be exchange1.mypublicdomainname.com. You
should not have to add anything to hosts or lmhosts file for
exchange1.test.local.


/neo

PS - By the way, since I don't know if you are configuring Outlook 2003 to
use rpc/https on fast connections as well as slow, I will warn you that if
Outlook 2003 tries an RPC connection first, it could take up to 2 minutes
before it fails over and tries a RPC/HTTPS connection.

"Stephen Bausch" wrote in message
...
Neo,
Thanks for the response. The problem here is not really with the
certificate. I can get a certificate with a valid FQDN for the server,
and I
can get that certificate installed on the laptop. The problem is in the
outlook account settings, specifically in the exchange server settings for
a
profile. When I specify an exchange server name, and then a user name,
outlook goes out and connects to the exchange server. When it connects,
it
changes the name of the exchange server in that box to
exchange1.test.local.
This exchange server name will keep switching back to that name, even if I
type in a different FQDN. So that is where we are stuck. When then
laptop
leaves the office, and they do not have a hosts file, they can no longer
find
the server exchange1.test.local. I can set the FQDN of the SSL proxy
server
for RPC over HTTP, to whaterver I want, so the problem is not really
there,
rather the problem exists in the outlook profile config of the exchange
server.

"neo [mvp outlook]" wrote:

Assuming this is a single server site and the SSL certificate shows
issued
to exchange1.test.local, then I think your stuck. Ideally if issuing the
certificate from your own CA, the SSL certificate should be issued to the
FQDN on how the server will be accessed from the internet. This should
eliminate the host file because the only thing that Outlook will fail the
connection on is when "Issued To:" line on the SSL certificate doesn't
match
what is listed in the Exchange proxy settings on the client.


"Stephen Bausch" Stephen wrote in
message
...
Here is the question and I appreciate your help in advance.


We have a client that has a windows domain with a .local fqdn, lets
call
it
test.local.
The exchange server name is exchange1, which gives us a fqdn for the
exchange server of exchange1.test.local.
We have setup RPC over HTTP, with a SSL certificate and it works. If
we
setup an outlook client on the network to use RPC over HTTP it works ok
(on
the same LAN as the server). We ran outlook /rpcdiag, and found that
the
client is communicating with the server with RPC over HTTP. That works
ok.
Now if we have an Outlook Client that resides outside of the LAN,
somewhere
else on the internet, in order to make RPC over HTTP work, we are
required
to use a Host File. The host file will contain an entry that points
the
address exchange1.test.local to the external address of the firewall
(which
routes SSL to the exchange server). That works fine.
The question is this,
Laptops that travel back and forth between the office and out off
the
office, cannot use this configuration. If I do not use a host file as
described about, the Outlook Client will work inside the office, but
will
not work from outside the office. If I use the host file described
above,
the outlook client will work when outside of the office, but not from
within
the office.
The problem is clear, the Laptop cannot determine the IP address for
exchange1.test.local when outside of the office, and the host file is
not
present. When the host file is present, and the computer is plugged is
on
the LAN, it tries to connect to the wrong IP address.
In the outlook 2003 configuration, there are two locations to place
the
computer name of the exchange server. The first is under Exchange
Server
Settings, and the second location would be under Exchange Proxy
Settings.
It seems that we need to use the FQDN of the exchange server
(exchange1.test.local) in order to connect to the exchange server
properly.
Do you know of a way to get arround this problem?