In our exchange 2010 environment when setting up Outlook with one of the mailbox accounts, check name resolves the FQDN of our Client Access Server. We do not want employees/customers to see this information. I have a subdomain whos name record is pointed at the CAS server, so all is great until you hit the "check name" button during setup and it resolves to the FQDN of the server.

exchange.mysite.com turns to EX-CAS01.mysite.local alt text

I am trying to figure out how to keep this from happening because it doesn't look as good, but more importantly for security purposes.

  • 3
    security through obscurity is not really security
    – Zypher
    Sep 9, 2010 at 21:20
  • I can't think of anything insecure about knowing the server name. It's childishly easy to find out anyway. Hell, Outlook will even tell you.... Sep 9, 2010 at 21:28

2 Answers 2


You can get around this by setting up a singe server CAS Array if that's what you really want to do.

Create a DNS entry for exchange.mysite.com on your internal DNS server and point it to your Exchange server. Then do this:

New-ClientAccessArray –Name “CAS Array” –Fqdn “exchange.mysite.com” –Site “Default-First-Site-Name”
Set-MailboxDatabase DatabaseName -RpcClientAccessServer “exchange.mysite.com”

You may even be able to get that to work without the CAS Array part, I just haven't tried it and probably wouldn't recommend it as Microsoft probably wont' support it.

  • I will put a caveat of I haven't tested this on this, but can't you just nslookup the CAS Array and it will return the FQDNs of the servers in the array? Sep 9, 2010 at 21:47
  • @Ben - If it's a C Record, yes. If it's an A record, no. If there's reverse DNS lookup, one could lookup the A record for exchange.mysite.com and then lookup the IP address that's returned. That could be fixed by changing the PTR record.
    – Jason Berg
    Sep 9, 2010 at 22:00

That looks normal to me. That field will resolve to the internal NetBIOS or FQDN of the server, not the public FQDN of the server (to which the SSL certificate is bound). I don't think there's anything that can be done about it. What is it about it that makes you think it's a security risk? How does knowing the internal name expose the server or client to any risk?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.