Re: Somewhat Urgent - Exchange 2007 Configuration Question



On Feb 10, 10:57 am, "Derek Martin"
<argo_mar...@xxxxxxxxxxxxxxxxxxxxx> wrote:
I'm curious to see what the mapping for the Services column looks like. My
MAPI clients need to not use (or supress error messages) for my external
cert. Here is an example of mine:

Thumprint Services Subject
xxxxxxxxxxxx .IP..
OID1.2.840...
xxxxxxxxxxxx S...W CN=....<my
public cert>
xxxxxxxxxxxx SIP..
CN=...<internal address name>

I think I might have something in needing to enable the internal address
cert to serve up MAPI but...not sure how.

???

"steveb" <swb_...@xxxxxxx> wrote in message

news:eSITIPTTHHA.4632@xxxxxxxxxxxxxxxxxxxxxxx



This shows the output of command "get-exchangecertificate" showing that
their are two certifcates assigned on this server.

[PS] C:\Documents and Settings\swbca>get-exchangecertificate

Thumbprint Services Subject
---------- -------- -------
96FF4BE2E7B4967BD0839DE35C4E4F9B2FBA5477 SI... CN=dc2
AC51733FFA3157CE581494A59C8B7CB0D16FD44A SI... CN=dc2
2BEE312E7491CE56E1D54FF33FDC983C605A4D76 ..P.W CN=owa.public.com,
OU=Scriver, O=xxx, L=xxx, S=xxxx

"steveb" <swb_...@xxxxxxx> wrote in message
news:EFF21452-F63E-492B-A163-BCA60DD7F609@xxxxxxxxxxxxxxxx
You may get a more precise answer from someone else . . . . but I manage
to resolved the internal / external certificate issue. It appears you can
assign different certificates for different protocols. Initially I had
the same issue that you did with Outlook after assigning a public domain
name certificate in IIS. After assigning the pubic domain certificate in
IIS I found that pop3S certificate was still using the local host name
certificate. Using the help files in Exchange I found the commands for
assigning the public certificate for pop3S and the local host certificate
for "Exchange" so Outlook clients no longer get the certificate warning.

I should have saved the scripts i found for next time .

"Derek Martin" <argo_mar...@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:29523158-E42B-4225-ADDE-759B2B8A4D88@xxxxxxxxxxxxxxxx
Good morning list...some background:

My new EX07 server is called app7.myddomain.com. It is a single server
(no edge role) and user mailboxes are therefore on app7.
I publish mail.mydomain.com as the external SSL certificate and access
point.
The SSL certificate for IIS is registered to mail.mydomain.com
Access tohttps://mail.mydomain.com/owaworks great.
User mailboxes are configured to look at Exchange as app7.mydomain.com
inside Outlook (it is also what is 'autodiscovered'.

Two questions:
1. Users inside the firewall, when opening up Outlook 2007, get an SSL
warning that the certificate name doesn't match (the cert being
presented is mail.mydomain.com)...How can I either A) supress that or
(more better) B) fix that so that it doesn't use or attempt to use the
SSL cert.

2. My user's synch issues folders are action packed with:
9:14:30 Microsoft Exchange offline address book
9:14:30 Not downloading Offline address book files. A server (URL)
could not be located.
9:14:30 0X8004010F

(Happening every 2 minutes on all users) - any pointers on where to go?- Hide quoted text -

- Show quoted text -

Here's what worked for me:
Assuming all the following are true, the problem is likely a public
DNS issue:

- You have configured the OAB for web distribution correctly.
- The client computers having this issue are located across a security
device or outside your corporate network (The Internet, etc.) where
your internal DNS records are not replicated.
- These clients are using the Outlook Anywhere feature in OL2007.

Apparently, the OAB download activity is handled by the Autodiscover
feature in OL2007. When downloading the OAB, Outlook tries to connect
to a web services Url found on the Client Access Server that resides
in an IIS virtual directory called "autodiscover", and access a file
called "autodiscover.xml". If the OAB is not configured correctly for
web distribution, this file will likely not exist, and your day will
be ruined. On the other hand, if the file exists, then you should be
able to test client connectivity to the web service by doing the
following:

1. From the client machine, open a web browser.
2. Navigate to http://<mail-server>.<your-email-domain-name>.<ext>/autodiscover/autodiscover.xml.
3. Enter your credentials when prompted.

You will get a 600 error. This is ok. It means you are connecting to
the autodiscover service, and that you don't have an issue with access
to the web service from the client.

By default, Outlook will look for and try to connect to the following
preset Autodiscover web service Urls in this order when looking for
the "autodiscover.xml" file:

https://<your-email-domain-name>.<ext>
https://autodiscover.<your-email-domain-name>.<ext>
http://<your-email-domain-name>.<ext>
http://autodiscover.<your-email-domain-name>.<ext>

In a nutshell, if you don't have a public DNS "A" record for
"autodiscover.<your-email-domain-name>.<ext>", then your OAB downloads
will fail miserably, and you will get "0x8004010F" synch errors in
Outlook. Since public DNS records take 24 to 48 hours to replicate
and become effective, you will likely need a workaround during that
time. The easiest interim fix is to modify the client computer's
hosts file to include an entry for the autodiscover host name, binding
it to the ip address of the CAS or mail server. For example:

65.223.187.51 autodiscover.your-email-domain.com

This is just an educated guess, but it is likely that the reason
internal clients (domain member computers) that are configured to use
Outlook Anywhere (like laptops) don't have this issue is because of
the integrated nature of DNS and Active Directory. Even though you
probably don't have an "A" record for the "autodiscover" host
internally, Outlook still seems to connect to the web service just
fine. I would be interested to know if my thoughts on this are
accurate, but I have already spent enough time on this issue...
Good luck!

.



Relevant Pages

  • RE: Outlook HTTPS over RPC error - Inconsistent users
    ... If the clients are using Outlook with PRC over HTTP and issue ONLY occurs ... issue which means it might be a client Outlook configuration or workstation ... over HTTPS because there is a problem with the certificate assigned to the ... With RPC over HTTPS no such pop up ...
    (microsoft.public.windows.server.sbs)
  • Re: Radius Server
    ... > so I'm guessing the client needs the Server Certificate, ... > export it from the server and import it to the client. ... >> But if you deployed EAP-TLS, you need a server cert and a client ...
    (microsoft.public.windows.server.networking)
  • Re: OWA Form Resetting
    ... Depends on the client browsers... ... The reason why you are getting alerts regarding the certificate being ... both the ISA server computer as well as the external ... I can view the cert and the certs ...
    (microsoft.public.isa)
  • Re: (New Subject): How to eliminate prompt for credentials when using RPC over HTTP
    ... > that it is installed on the client running Outlook 2003. ... > *Certificate Configuration* ... > Security Alert pops up regarding the certificate. ...
    (microsoft.public.windows.server.sbs)
  • (New Subject): How to eliminate prompt for credentials when using RPC over HTTP
    ... that your Outlook 2003 client must be running on XP Pro for this to work. ... *Certificate Configuration* ... To avoid the security alert pop-up, ...
    (microsoft.public.windows.server.sbs)