Exchange 2010 SAN Certificate

[MeTed]

I am doing a migration to Exchange 2010. I need to acquire a SAN Cert, but
I'm a little confused as to what info I need in order to process the cert.
Let's say I have a single Exchange 2010 Server that I want to do Outlook
Anywhere, Webmail, and Mobile support. My server (internal) is
dvs00.domain.local. My current public DNS record is exch.domain.com. Is
this the proper CSR command?:

Set-Content -path "C:\exch_domain_com" -Value
(New-ExchangeCertificate -GenerateRequest -KeySize 2048 -SubjectName "c=US,
s=Washington, l=Seattle, o=COMPANY, cn=exch.domain.com" -DomainName
dvs00.domain.local, dvs00, autodiscover.domain.com -PrivateKeyExportable
$True)

Will this satisfy my needs for internal and external?

TIA

[Rich Matheisen [MVP]]

Pretty much. I'd add a path name after the "-GenerateRequest" just so
I know where it's going.

exch.domain.com is what you'll use for Outlook Anywhere, OWA,
ActiveSync, SMTP, POP, and IMAP?

I'd rethink the use of different names for internal and external
access, though. That's a good way to drive users nutz. Better to have
a split-DNS and use the same name inside and outside. That's not a
requirement, but you should consider it.
---
Rich Matheisen
MCSE+I, Exchange MVP

[MeTed]

Thanks...Just out of curiosity, what gripes do you think the users would
have?

"Rich Matheisen [MVP]" <rich...@rmcons.com.NOSPAM.COM> wrote in message
news:qpb726trei7nltsn2...@4ax.com...

[Rich Matheisen [MVP]]

On Fri, 25 Jun 2010 05:40:41 -0700, "MeTed" <Me...@meted.com> wrote:

>Thanks...Just out of curiosity, what gripes do you think the users would
>have?

If they use Outlook? None. Outlook will use the SCP objects in your AD
to locate the CAS servers (for autodiscover). For those that use OWA:

<whine>
I used https://exch.company.com at {home|hotel|customer site} and it
worked. When I try it from Bob's PC in his office it doesn't work.
</whine>

Of course, you may let people on your LAN contact the external IP
address assigned to exch.company.com, but that kinda defeats the
purpose of having a DMZ. Or you may tell them, "Well, of course not!
You should remember to use https://dvs00.company.local when you're on
the LAN!". That usually doesn't go over very well.

For those that use WiFi instead of OTA synchronization with mobile
devices the problem will be the same as OWA, but now they have to
change the ActiveSync settings to get things to work. Again, that's
not somthing that goes over very well. :-)

Using a common name for resources and using two DNS servers makes this
a whole lot easier on the help desk and the users, and it ony takes a
little more work on your part to do it.