Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Windows Server 2012 R2 Active Directory Name
I need to setup a new Windows 2012 R2 server for a client. This server will also serve and a AD DC. I want to set the AD Domain name the same as the public website this company owns _ _ _ _ _ _ _ _funeralservice.com (27 characters including .com). This company does not own another public domain name. I know that the NETBION name allows up to 15 characters, and I would like it to match the domain name. What are my options if any?
So if I name the Domain name the same as the public domain name ( _ _ _ _ _ _ _ _funeralservice.com), then the user login will be _ _ _ _ _ _ _ _funeral\User1. I mean this will all work, but its a bit awkward that they do not match. I was just thinking of going with the .local route, but all the articles I have found suggest not doing so. What would be the best resolution? I do not believe the client is willing to purchase another shorter public domain.
Also, should the domain include a subdomain such as internal. _ _ _ _ _ _ _ _funeralservice.com, or LAN. _ _ _ _ _ _ _ _funeralservice.com? I have heard references there is a need to create a subdomain for the the AD domain name to avoid future conflicts. I am not sure about the need to do all of that though. I do not want to complicate things for a very small office network with one or two servers with less than 10 employees. What's your take on all of this?
So if I name the Domain name the same as the public domain name ( _ _ _ _ _ _ _ _funeralservice.com), then the user login will be _ _ _ _ _ _ _ _funeral\User1. I mean this will all work, but its a bit awkward that they do not match. I was just thinking of going with the .local route, but all the articles I have found suggest not doing so. What would be the best resolution? I do not believe the client is willing to purchase another shorter public domain.
Also, should the domain include a subdomain such as internal. _ _ _ _ _ _ _ _funeralservice.com, or LAN. _ _ _ _ _ _ _ _funeralservice.com? I have heard references there is a need to create a subdomain for the the AD domain name to avoid future conflicts. I am not sure about the need to do all of that though. I do not want to complicate things for a very small office network with one or two servers with less than 10 employees. What's your take on all of this?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Right now this office does not host their own email, and they currently use an aol.com address. I would like them to upgrade to office365 using their domain name even though its so long. So, I want to ensure I get the domain setup right from the start to anticipate future needs. Feedback is appreciated.
My advice - don't name their AD the same as their public name, unless you are fully prepared to deal with the issues you will face accessing the website from inside the domain. Mostly these manifest when you want to access the website using a URL like "http://xxxxfuneralservice.com". If you only access the website using "http://www.xxxxfuneralservice.com", and the website is never coded to use resources from http://somefuneralservice.com, then you should be fine.
However, to avoid all that, and also handle the name length, I'd suggest making the AD domain a subdomain of "xxxxfuneralservice.com". For example "ad.xxxxfuneralservice.com
However, to avoid all that, and also handle the name length, I'd suggest making the AD domain a subdomain of "xxxxfuneralservice.com". For example "ad.xxxxfuneralservice.com
The client always has their website "www._ _ _ _ _ _ _ _funeralservice.com" up and running on their conference room computers. These computers connect to large TVs mounted on walls. So its a definite issue. So you are saying, when I enter the domain name I should enter "ad._ _ _ _ _ _ _ _funeralservice.com"? How will the NetBIOS name appear then? What mean is, how will the user enter the domain to login, ad\User1, ad._ _ _ _ _ _ _ _funeralservice.com\User1.
I am thinking the user would simply enter ad\User1, and this will also address any issues accessing www._ _ _ _ _ _ _ _funeralservice.com from any computer withing the AD domain.
If that is the case, instead of using ad, I will use the owner's initials (JTM) to make is easier and more recognizable to the user should they need to enter a domain name at any point, etc. I suppose this solution will also address any issues if and when implementing hosted O365 email as well. I want to use the same public domain as their email domain instead of @aol.com. I just want to ensure I have everything setup with the internal domain beforehand.
Thank you for your feedback.
I am thinking the user would simply enter ad\User1, and this will also address any issues accessing www._ _ _ _ _ _ _ _funeralservice.com from any computer withing the AD domain.
If that is the case, instead of using ad, I will use the owner's initials (JTM) to make is easier and more recognizable to the user should they need to enter a domain name at any point, etc. I suppose this solution will also address any issues if and when implementing hosted O365 email as well. I want to use the same public domain as their email domain instead of @aol.com. I just want to ensure I have everything setup with the internal domain beforehand.
Thank you for your feedback.
A few things going on here, so I'll take them one at a time.
1) For your AD domain name, I'd use something like corp.<public domain name> Private names like .local are problematic when trying to secure resources behind a firewall with certificates. You may not have a need to do so today, but the future is unwritten and renaming an entire domain is downright painful.
2) Using just <domain name> for AD causes DNS issues that can be equally painful. Using a private subdomain like corp.<domain name> allows easy separation of DNS, allows legitimate purchases of public SSL certificates, and additional subdomains if expansion requires them. It is the most flexible forwardlooing option.
4) Regarding logins, <NETBIOS>\<username> has been considered "legacy" since Windows 2000. It is a throwback to NT days. However there has been little to no pressure to learn anything new (if a 16 year old change can still be called new) so that's the fallback. However, now there is a good reason.
5) Train users to log in with <username>@<public domain> ...that's been the standard since 2000.
6) Learn about UPNs. They let you make a user's login domain different than the AD domain. So that is the difference between a user logging in as user@domain.com instead of user@corp.domain.com
7) Done properly, their login can match their email address. Easy for them to remember.
8) Why this is a good thing to learn now? Azure Active Directory is increasingly powering a ton of technology behind windows, and *it* really wants user@domain.com for logins. If you use Office 365, now or in the future, this lets users logins be shared between on-prem and in the cloud, for example.
9) Even if you never use O365, Windows 10's "Windows Store for Business" can use Azure AD accounts for corporate control of store apps, incuding revoking licenses when necessary. Win10 will increasingly rely on Azure AD for business. And Azure AD is free.
If you plan right, and educate, this can be painless for users, actually makes a more consistent user experience, and helps future-proof your deployment. Hope that helps.
1) For your AD domain name, I'd use something like corp.<public domain name> Private names like .local are problematic when trying to secure resources behind a firewall with certificates. You may not have a need to do so today, but the future is unwritten and renaming an entire domain is downright painful.
2) Using just <domain name> for AD causes DNS issues that can be equally painful. Using a private subdomain like corp.<domain name> allows easy separation of DNS, allows legitimate purchases of public SSL certificates, and additional subdomains if expansion requires them. It is the most flexible forwardlooing option.
4) Regarding logins, <NETBIOS>\<username> has been considered "legacy" since Windows 2000. It is a throwback to NT days. However there has been little to no pressure to learn anything new (if a 16 year old change can still be called new) so that's the fallback. However, now there is a good reason.
5) Train users to log in with <username>@<public domain> ...that's been the standard since 2000.
6) Learn about UPNs. They let you make a user's login domain different than the AD domain. So that is the difference between a user logging in as user@domain.com instead of user@corp.domain.com
7) Done properly, their login can match their email address. Easy for them to remember.
8) Why this is a good thing to learn now? Azure Active Directory is increasingly powering a ton of technology behind windows, and *it* really wants user@domain.com for logins. If you use Office 365, now or in the future, this lets users logins be shared between on-prem and in the cloud, for example.
9) Even if you never use O365, Windows 10's "Windows Store for Business" can use Azure AD accounts for corporate control of store apps, incuding revoking licenses when necessary. Win10 will increasingly rely on Azure AD for business. And Azure AD is free.
If you plan right, and educate, this can be painless for users, actually makes a more consistent user experience, and helps future-proof your deployment. Hope that helps.
Yes. Using that example, the NETBIOS name would be "ad", and yes that's how the login would look (ad\User1).
You may also become familiar with userPrincipalNames (UPN) which can also be used to logon. They are in the form of username@upnsuffix. By default the UPN suffix is the same as the domain name, so a complete UPN would be "user1@ad.___funeralservic
Edit: I see Cliff posted while I was typing. I'm glad to see he expounded on UPNs.
You may also become familiar with userPrincipalNames (UPN) which can also be used to logon. They are in the form of username@upnsuffix. By default the UPN suffix is the same as the domain name, so a complete UPN would be "user1@ad.___funeralservic
Edit: I see Cliff posted while I was typing. I'm glad to see he expounded on UPNs.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial