Windows SBS 2011

I'm unaware of the SSL issue you describe, and I can't see why that would be a showstopper - it's possible to use a dot-local internal domain suffix without requiring a dot-local SSL, and ignoring that, SBS2008 AND SBS2011 work using a single name SSL certificate which is only valid for the external, internet FQDN.

The Macs don't like the dot-local, but SBS doesn't like the Macs so it's a hate-hate thing.

To create a SBS2011 domain with a non .local domain you need to install using an answer file which you can create from the install DVD:

http://blogs.technet.com/b/sbs/archive/2011/01/21/introducing-the-sbs-2011-answer-file-generator.aspx

Nice one Cliff - you put it far better than I could

I still see a lot of handwringing about whether or not to use .local though...
http://en.wikipedia.org/wiki/.local

The short answer is - you don't need to add the internal .local name of the SBS in the SSL certificate.

This is one of the nice extras that come with SBS - automatically adjusting the SCP (Service Connection Point) and Exchange Web Services URL, when you run the Setup Internet Address wizard.

As a result, the internal name of the SBS (ex. yourSBS.yourdomain.local) which is configured by default when Exchange 2010 is installed, is replaced automatically with the SBS public name (ex. remote.yourdomain.com) after yiu run the Setup Internet Address wizard. Actually, a lot of stuff happens in the background, including requesting a SSL certificate from the SBS CA and assigning it to the Exchange and SharePoint directories.

You can confirm this easily, by running the following commands in EMS (Exchange Management Shell):
1. The adjusted SCP:
Get-ClientAccessServer | FL *InternalURI

2. The adjusted Web Services URL:
Get-WebServicesVirtualDirectory | FL  *InternalURL

3. The PinPoint DNS zone for the Public SBS name created automatically - in DNS manager:

Bottom line - the internal SBS name is not needed in the certificate, as it is not used by the SCP and Web Services URL.

Therefore you have the following choices:
A. Continue using the SSL certificate, issued by the SBS CA (Certificate Authority). This means, you need to install the certificate package on remote clients.

B. Request and install a single name SSL certificate. Considering the fact, that you can get one for free from StartSSL (not a trial but a filly functional one year certificate). In this case, you need to configure a SRV record in the external DNS zone, and remote OA (Outlook ANywhere) users will get a redirection popup. This is fine with a handful of users, but gets a problem when you have a lot of remote users.

C. You can get a UCC (Multiple Domain) certificate. In this case you are just fine with the Public SBS name (ex. remote.yourdomain.com) and the autodiscover name (ex. autodiscover.yourdomain.com). Of course, you have at minimu five slots for domain names, so you can add names like mobile.yourdomain.com etc.

Again, the above is valid only for SBS users. Those with a standard Exchange install, will need to adjust manually the SCP and Web Services URL, before using a UCC without the internal Domain name included. Internal Outlook Clients, are connecting to the specified internal URL and if it is not included in the certificate they get a security popup window.

One last advice, if you go with option C - make sure that the SBS public name is specified as a CN (Common Name) in the requested UCC. Failure to do so will result in connectivity issues for remote OA users running XP or Vista (pre SP1).

Best Regards,
<removed by SouthMod>
TwitterButton.png