Outlook 2007 Security pop up (Exchange 2007 on SBS 2008)

It very well could be due to your OAB trying to download from an old location/name.  Also, make sure your SSL is not self signed and that it's from a 3rd party.

Try this:  Hold down the ctrl key and right-click the Outlook icon in the system tray, then select Test Email AutoConfiguration.  Look for the old server name anywhere and let us know the results.

All is OK this side. There is only in the HTTP section, under Unified Messaging, that there is still the old address. But we don't use Unified Messaging here.

Some computers are on Outlook 2010. One in particular still tries to connect to the server with the email address as login information, with no other choice than cancel. From time to time it try to connect with smart card, which is not used here, not even configured... it can't find valid certificate.

I looked around in the computer local certificates but there is only the server-CA installed.

The other thing that I don't understand is why does it try to connect with the email address as login information while I recorded the login and password with the emailaddress@domain.local as login information.


Edit:

One another computer still try to use the old Dyndns certificate from the outside (in RPC over HTTP). Could I remove the old certificate in Exchange 2007 without riking to disturb the normal opération (which is not so normal for the moment...) ?
If so, I suppose that I should do that, how to do it gently in Power Shell please ?

Can I just remove all dnynds certificates from Exchange with Power Shell (remove-exchangecertificate DED1ER5F41R4R1CFE25R4F65ER41), even the still valid ones (which are normally not used again) without the need  to reactivate the new one ?

Thank you for your time !

I'd give removing the certs a shot.  You won't impact flow, but just make sure to back them up in case you need them again.  You will get a few cert warnings per the expected norm when doing this.  But if this fixes your pop up then get a 3rd party cert (a UC SSL is what you're looking for; Comodo, GoDaddy, Entrust, VeriSign, etc. are all places to get one) and install it.

Let me know if you need help doing that.

OK, old certificates are backed up and removed from Exchange.

We still experience ask for connection popups. When we create new profies, the popup is different, it is a smart card ask popup. Autodiscover website in  IIS is set to ignore clients certificates. OAB URLs are both remote.domain.com (Which ping from inside and outside correctly) and Outlook email accounts are set to negociate authentication. I run an iisreset with no different result.

What can I check now ?

Any idea?

Let me do a little more research, but try looking at this first:

http://social.technet.microsoft.com/Forums/exchange/en-US/f99813ed-8a5f-4fee-8ccc-4bfccd3dedd8/exchange-2010-prompts-for-password-when-downloading-oab-please-help

I found this error in  BPA :

Certificate SAN mismatch: The subject alternative name (SAN) of SSL certificate for https://domain.dyndns.biz/Autodiscover/Autodiscover.xml does not appear to match the host address. Host address: domain.dyndns.biz. Current SAN: DNS Name=remote.domain.com, DNS Name=www.remote.domain.com, DNS Name=server1.domain.local, DNS Name=autodiscover.domain.local.

I don't know where does this URL is wrtitten because when I test Autodiscover from Outlook, all is set to the remote URL except in the Protocol HTTP section under unified messaging. Unified messaging in RPC protocol is set to the remote URL. I precise that we don't use UM...


Where can I find that false URL to replace it ? Or else, do you know how to replace directly ?


Thank you very much for your help, best regards,

The first thing I would do is reissue your SSL cert.  Get these names:

If your domain is abc.com, then get:

MAIL.ABC.COM as the main name and add the following 5 names as SAN (subject alternative names)

We don't use the mail.domain.com in our certificate. Users have email addresses on domain.other, we just use domain.com for OWA and remote, all the MX of domain.com are Host servers in another country. On our certificate, there is remote.domain.com first then EXCserver.domain.local and autodiscover.domain.local, no autodiscover.domain.com (maybe the issue is from here). The website domain.com is hosted by a Host service, so I suppose that we do not have to put the name domain.com isn't it ?

Why do we have to put EXCserver and EXCserver.domain.local if we have the second one?

If you already have EXCserver.domain.local then don't worry about the NetBIOS name you can just leave that.  As far as the autodiscover goes, whatever autodiscover address is being used will need to be on the cert.  So if you're using autodiscover.domain.com then it has to be on the cert.

Hello,

Sorry for the delay...
We "Fixed" the issue by forcing the RPC over HTTP connection even in fast Networks. It Works because the remote and local URL are the same (remote.domain.com). So, the issue must be in the local configuration of RPC isn't it ?

It still was two old binding to port 80 for the dyndns.biz URL in the SBS Application Website. I removed it but it changed nothing to the situation.

What can I check now please ?

We will re-issue the SSL certificate but for now, we have to fix the problem which clearly inside the local network, what do you think ?

Thank you for your help !

There is a lot of websites in IIS. The Default Website is turned off, instead there is the "SBS Web Applications" binded on port 80 for "sites" and have also another binding for http with the name remote.domain.local. In this site, the https (443) is binded to the GoDaddy certificate called "Microsoft Exchange" but no name appears as you can see in the attached screenshot.

I found that there is again two valid certificates, issued by the SBS-Server-CA itself with IMAP, POP and SMTP services activated. The GoDaddy certificate is activated for IIS, SMTP, POP and IMAP. Do I have to remove these SBS-CA issued certificates  or could I let it as is ?


Thank you in advance for your help, best regards,
SBS-Web-Apps-Bindings.jpg

Thanks anyway.