Adding a domain to the Active Directory is something that you don’t do quite often. But with a hybrid environment with Office 365 you may have noticed that you will need to add a new domain to your local Active Directory as well. Now adding a new domain isn’t particularly hard to do, you only need to know where.
In this short article, I will show you how you can add a new domain to your active directory in a few simple steps.
How to add a domain to the Active Directory
- Login to your domain controller
- Open the “Active Directory Domains and Trusts”
- Open the Properties of Active Directory Domains and Trusts
Right-click on the top item in the left tree view and select properties
- Add the new Domain Name
In the UPN Suffixes dialog, enter the new domain name in the “Alternative UPN Suffixes” field and click on Add
- Apply the settings
Click Apply and close the windows. The domain is now added to the domain controller.
- (optional) for replication to other domain controllers
If you have multiple domain controllers you can force the replication with the following command in PowerShell / CMD: repadmin /syncall /AdeP
You should now be able to use the new domain name in the Active Directory or in the Exchange Administration Center.
Conclusion
As you can see it’s pretty simple to add a new domain name. Adding a new domain name won’t affect any current users, so you can safely add it, and then make changes to the users accordingly.
If you have Office 365, and use AD Sync, then you will need to add the domain to Office 365 as well. You won’t need to change anything for AD Sync self.
There are several reasons why you might need to implement multiple domains. These reasons include such considerations as:
Scalability Although Microsoft has designed Active Directory to accommodate millions of objects, this number may not be practical for your current environment. Supporting many thousands of users within a single domain places higher disk space, CPU (central processing unit), and network burdens on your domain controllers. Determining the scalability of Active Directory is something you have to plan, design, test, and analyze within your own environment.
Reducing replication traffic All the domain controllers of a domain must keep an up-to-date copy of the entire Active Directory database. For small- to medium-sized domains, this is not generally a problem. Windows Server 2003 and Active Directory manage all of the details of
transferring the database behind the scenes. Other business and technical limitations might, however, affect Active Directory's ability to perform adequate replication. For example, if you have two sites that are connected by a very slow network link (or a sporadic link, or no link at all), replication is not practical. In this case, you would probably want to create separate domains to isolate replication traffic. Sporadic coverage across the wide area network (WAN) link would come from circuit switching technologies such as Integrated Services Digital Network (ISDN) technologies. If you didn't have a link at all, then you would have a service provider outage or some other type of disruption. Separate domains would, of course, separate replication traffic, but if this is the case, the amount of administrative overhead is increased significantly.
Because it's common to have WAN links in your business environment, you will always need to consider how your users authenticate to a domain controller (DC) so a DC at a remote site is commonly seen to authenticate users locally to their local area network (LAN).This setup is the design you will most likely see at any given location or business that has used Microsoft TechNet as a reference tool. The most common design involves putting a DC at each remote site to keep authentication traffic from traversing the WAN. If it were the other way around, the authentication traffic that may cause the WAN may cause users problems if WAN utilization is high or if the link is broken and no other way to the central site is available. This design has many flaws, so the design most likely seen is one where each server must now replicate its database of information to each other server so that the network and its systems converge.
As just mentioned, is important to realize that the presence of slow WAN links alone is not a good reason to break an organization into multiple domains and because of this, the most common solution is to set up site links with the Site and Services Microsoft Management Console (MMC). When you use this MMC, you can manage replication traffic and fine tune independently of the domain architecture. We'll cover these topics in detail in Chapter 4, "Configuring Sites and Managing Replication."
There following are the reasons why you would want to use a multidomain architecture, such as when two companies merge through an acquisition.
Meeting business needs There are several business needs that might justify the creation of multiple domains. Business needs can be broken down even further into organizational and political needs.
One of the organizational reasons for using multiple domains is to avoid potential problems associated with the Domain Administrator account. At least one user needs to have permissions at this level. If your organization is unable or unwilling to place this level of trust with all business units, then multiple domains may be the best answer. Since each domain maintains its own security database, you can keep permissions and resources isolated. Through the use of trusts, however, you can still share resources.
A political reason might arise if you had two companies that merged with two separate but equal management staffs, and two sets of officers. In such a situation, you might need to have Active Directory split into two separate databases to keep the security of the two groups separate. Some such organizations may need to keep the internal groups separate by law. If this is the case, a multidomain architecture is born to provide exactly this type of pristinely separate environment.
Many levels of hierarchy Larger organizations tend to have very complex internal and external business structures that dictate the need for many different levels of organization. For example, two companies might merge and need to keep two sets of officers who are managed under two different logical groupings. As you will see in Chapter 5, "Administering Active Directory," OUs are used to help group different branches of the company so that you can assign permissions, or delegations, or whatever else you can think of without affecting anyone else. Management of data becomes much easier when you're using OUs, and if designed correctly, will help you control your network right from one console. You may only need one level of management—your company may be small enough to warrant the use of the default OU structure you see when Active Directory is first installed. If, however, you find that you need many levels of OUs to manage resources (or if there are large numbers of objects within each OU), it might make sense to create additional domains. Each domain would contain its own OU hierarchy and serve as the root of a new set of objects.
Varying security policies All of the objects within the domain share many characteristics, one of which is the use of a security policy. A domain is designed to be a single security entity. If configured properly, the use of a domain will allow the assignment of usernames and password restrictions to apply to all of its objects located within. If you set a password length restriction to seven characters, then you can assign that same restriction to every object in the domain. If your organization requires separate security policies for different groups of users, you should consider creating multiple domains.
Decentralized administration There are two main models of administration that are commonly used: a centralized administration model and a decentralized administration model. In the centralized administration model, a single IT organization is responsible for managing all of the users, computers, and security permissions for the entire organization. In the decentralized administration model, each department or business unit might have its own IT department. In both cases, the needs of the administration model can play a significant role in whether or not you decide to use multiple domains.
Consider, for example, a multinational company that has a separate IT department for offices in each country. Each IT department is responsible for supporting only the users and computers within its own region. Since the administration model is largely decentralized, creating a separate domain for each of these major business units might make sense from a security and maintenance standpoint.
Multiple DNS or domain names Another reason why you may need to use a multidomain architecture would arise if you wanted or planned to use multiple DNS names within your organization. If you use multiple DNS names or domain names you must create multiple domains. Each domain can have only one fully qualified domain name (FQDN). A FQDN is the full name of a system that consists of a local host, a second-level domain name, and a toplevel domain (TLD). For example, www.wiley.com is a FQDN. .com is the TLD, www is the host, and wiley is the domain name (second-level). Although not seen, a "." exists at the end of .com; it represents the root.
To apply this to our example of a business need, let's consider two groups within a company: Sales and Engineering. For example, if you need some of your users within the sales.mycompany.com namespace and others in the engineering.mycompany.com namespace, you must use multiple domains. If the domain names are noncontiguous, you will need to create multiple domain trees (a topic you'll see covered later in this chapter).