Will our domain name cause problems?

[CathodeRay]

We just got a new server with SBS pre-loaded, and we named our domain (for example) "ABC.com". Prior to getting this server, we had created an *internet* domain of ABC.com (i.e.

http://www.ABC.com).

Now, as we are setting up the SBS server and wanted to use the companyweb, we think we may have messed up by naming our internal domain the same as our internet domain.

Will this cause us a problem when we start using Exchange? Should we have created our internal domain to be something different than ABC.com? (It seems so obvious now!)

Should we re-install, or is this no big deal?

 

[scottew]

You should have named it abc.local to make things easier. If this is a brand new server, personally I would start from scratch and reinstall SBS. It should only take a few hours.

Scott

 

[ShackDaddy]

I'm going to disagree and register what is usually a minority opinion (although not among experts). While people often like to use a non-live internal domain names internally, if you understand that your internal DNS is separate from your external DNS, it's easy to make using your public name work, and there are actually some advantages to using the same name internally and externally.

If you continue with the way you have things, know that you will need to get the IP address of your public web site and create an A-record for it in your internal DNS (

http://www 34.65.23.12)

in order to allow workstations in your network to access the public website.

When it comes to setting up Outlook over HTTPS (RPC-over-HTTPS, Outlook Anywhere), you will find that having the same server name internally and externally will simplify setup for your users.

Dave Shackelford
Shackelford Consulting

 

[CathodeRay]

Scott... thanks for the conventional advice. You're right, ultimately... starting that way makes things a lot less complicated.

I've got to admit, that after all is said and done, we DID name it ABC.local... but going through this exercise helped me, and hopefully will help others.

And thanks, ShackDaddy, for offering an alternate opinion... there are almost always ways to rig a solution, and I have found those to be ever so valuable over the years. And you nailed it on the RPC over HTTPS... I wrestled with that a couple of nights ago, with the solution being that I had to be connected via VPN to be able to authenticate enough to be able to complete the RPC setup. I'm still not 100% clear on that topic, but I bet if we had used ABC.com all around (and everything else had been setup correctly), then RPC would've fallen right into place.

I hate to admit how many years I've been in this business, and I'm still confounded by little stuff almost every day. I guess that's what keeps it interesting.

 

[scottew]

And you nailed it on the RPC over HTTPS... I wrestled with that a couple of nights ago, with the solution being that I had to be connected via VPN to be able to authenticate enough to be able to complete the RPC setup.

That is strange, the whole idea of RPC over HTTPS is so that you don't have to set up a VPN. I have our network set up with .local and I had no issues setting it up and I have about 100 remote users set up.

Scott

 

[ShackDaddy]

It may have something to do with whether you have purchased a 3rd-party cert or if you're trying to roll your own. If you are issuing a self-signed cert, your remote client will often fail to connect to RPC-over-HTTPS for the initial setup because it can't properly create the SSL connection without a copy of the self-signed cert, and the internal cert doesn't match the external domain name. If you initially set things up over a VPN connection, you get around that cert problem.

But if you have a either a 3rd party cert or use the same name internally and externally, it gets around that issue.

Dave Shackelford
Shackelford Consulting