How do I add custom domain to windows server?

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

So when you setup windows server you get the .local domain, how on earth do I add a custom domain? I would guess Id have to go into my domain provider and edit the DNS settings in someway but I have no idea how to get this on the server! If anyone can even find me a step by step article (I looked) it would be a great help.. The idea is to install exchange and create an on prem solution. I have the server with AD already and user accounts.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I'm not sure I follow, but I think if you're wanting to do this you're probably best watching server 2008/2012 videos on pluralsight etc or reading through some books and starting from scratch so you have a better understanding of everything.

It's pretty complicated to just dive into it.

When you setup AD you shouldn't just get a default .local suffix, I'm pretty sure you have to configure that during dcpromo unless windows server has drastically changed from 2k8 to 2k12. Off the top of my head there's probably a way to do it with alternate UPN suffixes and CNAME records or something. I still haven't completely wrapped my head around DNS and I've been studying it for ages. Someone else will know the answer, but I do think you'd be best off really studying Active Directory before trying to configure anything relatively complicated. It's a pretty deep rabbit hole.

 

It sounds like you want to add Accepted Domains in your Exchange so that your mailboxes can have an @foo.com and an @bar.net and so on. Otherwise they will have @thingy.local which isn't very internet routable.

 

So first of all you need to think about what it is you're trying to do, it's nothing to do with Windows server Domains but it does have something to do with DNS and MX records.

Now a couple of things you need to be aware of.

First of all is that routing email is done via MX records, that MX record needs to point to a static IP address that you would be listening for SMTP traffic on, ideally if you have a static IP address on your external interface on your router you would use that, then have a port forwarding rule to push all SMTP (port 25) to an internal address (your mail handling server, in this instance your Exchange server). Now it's important to remember that this MX record needs to be configured publicly with whoever your domain name is registered with, this is because that MX record then needs to be distributed around the net, that won't work with your own internal AD based DNS server.

Once you have the routing sorted out you're going to need to have Exchange configured to use the right domain name, something you're going to have to look in to yourself because it's not something I have done.

 

Thanks guys, yeah I understand all the mx records stuff etc and DNS records I know how to point things at different providers like google apps just bewil

thanks will have a read, I assume id have to configure the MX record to point towards exchange server though? And Im guessing the mx record would be the IP address?

 

In a network in which Active Directory Domain Services (AD DS) is deployed, the DNS Server role is most often installed on domain controllers. This simplifies DNS administration by making it possible for the Active Directory domain namespace and the DNS domain namespace to be maintained simultaneously. In some cases, however, it might be necessary to install the DNS Server role on a stand-alone server (that is, a server that is not a domain controller)—for example, to provide load balancing or to support a network that does not deploy AD DS.