Exchange 2007 Sercurity Alert

I installed a third party certificate for OWA. Everything externally works great. But whenever I reboot our exchange server, several internal outlook clients get this popup. I am trying to remedy that but before doing so, I am trying to fully understand the process. After following this article:

You need an internal record for mail.publicdomain.co.uk and autodiscover.publicdomain.co.uk that both point to the internal IP of your CAS server/CAS array. You also need to set the internal URLs on your web services to point to the these URLs.

I'm assuming that you have both hostnames on your certificate as well.

You need to either have autodiscover.publicdomain.co.uk on the cert or you need to setup SRV DNS records for your autodiscover service and change the internalURi of the autodiscover service to point to mail.publicdomain.co.uk

I've already set the internalUri for on my CAS server. BTW, I only have 1 exchange server hosting all the roles. So the only thing I am missing is the external DNS record pointing autodiscover.publicdomain.co.uk -> mail.publicdomain.co.uk

OK, I can do that. My only question now is most of the documents refer to adding this record as a solution for non-domain clients. We don't allow non-domain clients. I'm getting this security alert on domain clients that are in the same LAN as the CAS server.

No, that doesn't really apply. One thing I want to verify is that you are using split-dns. Meaning, you have both an internal and external zone (completely separate) for your publicdomain.co.uk zone. This allow you to set your internal A record for mail.publicdomain.co.uk to the internal IP of your Exchange server and the external A record of mail.publicdomain.co.uk to the external IP.

The reason you need to create the SRV record is for external clients. Outlook will attempt to connect to autodiscover.publicdomain.co.uk. Failing to connect to that, it will look for the SRV record. The SRV record will point to mail.publicdomain.co.uk. You need to use the SRV recond when your cert only has mail.publicdomain.co.uk. For internal clients, they will query AD for the autodiscover service. The value returned is what you set on the internaluri attribute on the Set-ClientAccessServer cmdlet. This value should be mail.publicdomain.co.uk since that is the only name on your cert.

Now you should see why you need split-dns. You could use a different zone internally. For example, you could have privatedomain.co.uk. You would then set all your internal urls on the web services to point to mail.privatedomain.co.uk. There are to caveats with this setup. First, you would need mail.privatedomain.co.uk added your SSL cert. Second, privatedomain.co.uk needs to be a domain that is registered to you and can't be a private domain like yourdomain.local. This is because you can no longer get SSL certs with private domain names.

If you don't have split-dns setup, you could also just have the one A record, which would point the internal clients to the public IP. This would work as long as your firewall and routers will allow your internal clients to use the external IPs.

Sorry that I am just getting back to you. That didn't work. I still get the same popup. One thing I did notice though is that if I click view certificate, the certificate is not the one I purchased and installed in exchange. It is for some other website/company altogether. Does this mean that the dns record is still propagating or something else is incorrectly configured?

Is there anything else I can try or info you would need to help troubleshoot this? I know speaking with fictitious domain names make troubleshooting a little more difficult. I do appreciate all the time and support you have given. Thanks,

Yes, we only get the certificate alert when our exchange server is offline. So when I do maintenance or just reboot, internal LAN users get that popup and begin calling help desk. Only some users get it. I was attempting to fix that so when I do maintenance, their outlook clients just show disconnected but they wouldn't normally notice that. The popup alerts them that there is something wrong and the begin hammering the help desk phones.

When I use nslookup, set type=srv, _autodiscover.publicdomain.co.uk, that points to my cas server. When I do an A record lookup, autodiscover.publicdomain.co.uk, that points to an unknown IP.

Ok, I think I figured it out. There is no A record for "autodiscover.publicdomain.co.uk" But there is one for "*.publicdomain.co.uk" So is that why it is forwarding the "autodiscover" request there?

If I were to remove the A record of "*.publicdomain.co.uk" how would that impact dns for our website? There is an A record of "www.publicdomain.co.uk". What if someone types just "publicdomain.co.uk" in a browser, would it still route them to our website?

The @ record just reference the part domain. So if you type in domain.com it direct to the IP you specify. The * record is a wildcard catch all. So, if someone types a host that doesn't exist in DNS is goes to the IP on this record. That is why you had trouble. You don't have an autodiscover record but this wildcard record was responding with an IP.

I appreciate all of your help with this. I do have one more question even though I already closed this. When I run the Microsoft Remote Connectivity Analyzer it fails the first three tests but succeeds on the fourth(SRV). The second test fails because we don't have a cert with a SAN. The third fails because we block incoming 80 traffic. The first fails and i know why but don't understand how to fix it. I am asking because it relates to the dns changes.

When it resolves that, it points at our website, not our mail server because the @. record points publicdomain.co.uk to the website. Is there a way to fix that without effecting the website or is that just the way it is? Thanks again for all your help and time. Greatly appreciated.

It is OK that it fails on those tests as long as it succeeds on one. In your case the SRV record. The test is replicating what Outlook does. Outlook has a list of autodiscover URLs it will try. When it fails on one, it moves to the next one until it either succeeds on one or fails on all of them.

Among the most obnoxious of Exchange errors is error 1216 – Attached Database Mismatch error of the Jet Database Engine. When faced with this error, users may have to suffer from mailbox inaccessibility and in worst situations, permanent data loss.

To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it.
The vast majority of email clients display l…

This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online)
The email signat…