Nathan,
We are experiencing this problem as well. The error message is that "the
CORRECT Root Certificate" is not installed. Can you explain a bit more
about how Entourage and SSL work to access delegated accounts? This error
message only appears if the user has a delegate account connection
established (e.g. the user has one or more shared calendars). I've
confirmed that these delegated accounts unlike the user's own data are being
accessed by Entourage through the backend server (where the mailboxes
reside) and not through our frontend server (as I assume it should?).
My specific questions are:
1) Since Entourage seems to be bypassing the frontend server and going
directly to the server with the mailbox, in order for SSL to be used I
assume that the backend server must at minimum be configured to respond to
SSL (port 443). Does it also have to have a certificate in order for
communication over SSL to proceed? If there were no certificate, then there
would be no response at all, correct?
2) If SSL AND a certificate must be present on the server, what is this talk
about "the correct root certificate"? Does that mean the server has a
certificate but not the correct one? If so, what might be some reasons it
is "not correct"?
3) I have used a web browser to go to the backend server using SSL (https
and we have a Equifax certificate for it. After being prompted for my
UserID and password, I can see the OWA public folder. If the browser has no
problem with the certificate on the server, why would/does Entourage?
4) If our server has a certificate from a known public authority such as
Equifax then there should be no need to install a copy of that certificate
on the client machine?
I'm afraid the implementation of trying to get Entourage to work with
Exchange has been most frustrating.
Here seem to be some basic steps that I believe that MUST be in place to
make the process work:
1) The DNS must provide the exchange server's domain in the list of search
domains. I discovered this from one university's web pages where they were
illustrating the need to do this on the client machines because evidently
like our university the exchange server's domain is NOT being reported from
the DNS. In simple lingo, this means the user must open System Preferences,
click on Network, get to the TCP/IP settings pane, and type in the exchange
server's domain in the "Search domains" text box and save those changes.
Without this, the Entourage setup wizard will never work in its
interrogation to determine the Exchange server settings. This is due to the
strange practice of Entourage using partially qualified IP names when it
interacts with the network. Thus it inquires who is "bill" rather than who
is "bill.domain"?
2) It should be documented clearly (so end users could have a chance to
manually configured Entourage) that the Directory server uses port 3268 for
communication with an Exchange server (click on the advanced pop-down
button). This is NOT the default port associated with most LDAP queries. I
spun my wheels for quite a bit because part 1 was failing and I did not see
any documentation on Microsoft's Exchange/Entourage web pages that brought
out this simple and critical point. This seems to be the default setting
with Exchange.
3) The delegation need for SSL and a certificate on possibly a DIFFERENT
server from the frontend server needs to be highlighted. We wasted a lot of
time and resources trying to track that down and we still have this
certificate warning problem remaining.
I recommend that Microsoft develop at minimum a simple troubleshooting web
page that at least provides a little direction to help speed up the process
of implementing Entourage. There would be less head banging and one step
forward, two steps back. They might start with the above points and include
others such as to be certain that the email field in the Entourage settings
is in the form of "userid@domain" and not "emailalias@domain"
Bill
