Domain controllers are servers that support Active Directory. Each domain controller has its own writable copy of the Active Directory database. Domain controllers act as the central security component in a domain.
All security and account verification operations are performed on the domain controller. Each domain must have at least one domain controller. For fault tolerance, we recommend that you install at least two domain controllers per domain.
In the Windows NT operating system, only one domain controller supported writing to the database, that is, a connection to a domain controller was required to create and change user account settings.
This controller is called primary domain controller (Primary Domain Controller - PDC). Beginning with the Windows 2000 operating system, the architecture of domain controllers was changed to allow the Active Directory database to be updated on any domain controller. After updating the database on one domain controller, the changes were replicated to all other domain controllers.
Although all domain controllers support writing to the database, they are not identical. In Active Directory domains and forests, there are tasks that are performed by specific domain controllers. Domain controllers with additional responsibilities are known as operation masters. Some Microsoft materials refer to these systems as Flexible Single-Master Operations (FSMO). Many people believe that the term FSMO has been used for so long only because the abbreviation sounds very funny.
There are five operations master roles. By default, all five roles are assigned to the first domain controller in an Active Directory forest. The three operations master roles are used at the domain level and are assigned to the first domain controller in the created domain. The Active Directory utilities discussed next allow you to transfer operations master roles from one domain controller to another domain controller. In addition, you can force the domain controller to take on a specific role as the operation master.
There are two operations master roles that operate at the forest level.
- Domain naming master- These operations masters must be contacted each time naming changes are made within the forest's domain hierarchy. The task of the domain naming master is to ensure that domain names are unique within the forest. This operations master role must be available when creating new domains, deleting domains, or renaming domains
- Schema master- The schema master role belongs to the only domain controller within the forest where schema changes can be made. Once changes are made, they are replicated to all other domain controllers within the forest. As an example of the need to make changes to the schema, consider installing the Microsoft Exchange Server software product. This changes the schema to allow an administrator to manage both user accounts and mailboxes at the same time.
Each of the forest-level roles can belong to only one domain controller within the forest. That is, you can use one controller as the domain naming master and a second controller as the schema master. In addition, both roles can be assigned to the same domain controller. This distribution of roles is used by default.
Each domain within the forest has a domain controller that performs each of the domain-level roles.
- Relative ID master (RID master)- The master of relative identifiers is responsible for assigning relative identifiers. Relative identifiers are the unique part of a security identifier (Security ID - SID) that is used to identify a security object (user, computer, group, etc.) within a domain. One of the main tasks of a relative identifier master is to remove an object from one domain and add an object to another domain when moving objects between domains.
- Infrastructure master- The task of the infrastructure master is to synchronize group memberships. When changes are made to group membership, the infrastructure master communicates the changes to all other domain controllers.
- Primary Domain Controller Emulator (PDC Emulator)- This role is used to emulate a Windows NT 4 Primary Domain Controller to support Windows NT 4 Backup Domain Controllers. Another task of the Primary Domain Controller Emulator is to provide a central point of administration for user password changes and user lockout policies.
The word "policies" is used quite often in this section to refer to group policy objects (GPOs). Group Policy Objects are one of the main useful features of Active Directory and are discussed in the corresponding article, the link to which is provided below.
In medium and large companies, it is common to use Domain Services to manage the corporate network infrastructure with one or more Active Directory domain controllers that form sites and forests. The domain services discussed in this article allow you to authenticate users and client computers, centrally manage enterprise infrastructure units using group policies, provide access to shared resources, and much more. The structure of identification and access of corporate networks Active Directory includes five technologies:
- Active Directory Domain Services (AD DS);
- Active Directory Certificate Services (AD CS);
- Active Directory Rights Management Services (AD RDS);
- Active Directory Federation Services (AD FS);
- Lightweight Directory Services (AD LDS).
Domain Services (AD DS) is considered the core technology of Active Directory. It is with the help of this service that you can deploy a domain controller, without which there is simply no need for basic services. The Active Directory Domain Services server role can be installed both using the graphical interface and command line tools in the full edition of Windows Server 2008/2008 R2, as well as in the server core editions of Windows Server 2008/2008 R2 using command line tools. This article will focus specifically on installing the AD DS role using the command line (both in the full version and in kernel mode, AD DS is installed using the command line tools in the same way). But before installing this role, I recommend that you familiarize yourself with some of the terms that are used in this technology:
Domain controller. A domain controller is a server that performs the role of domain services, or directory services, as it was called before, it also hosts the directory data store and the Kerberos Key Distribution Center (KDC) protocol. This protocol provides authentication of identity objects in an Active Directory domain.
Domain. A domain is an administrative unit within which computers, security groups, and users are located on the same network, managed by a domain controller, using the same specific capabilities. The domain controller replicates the partition of the data store that contains the identification data for users, groups, and computers in the domain. Moreover, user and computer accounts are not located locally on client computers, but on a domain controller, that is, network logon is used on all workstations. In addition, the domain is the scope of various administrative policies.
Forest. A collection of domains that use a single directory schema is called a domain forest. Essentially, a forest is the outermost boundary of a directory service, where the first domain established is called the root domain. Within each forest, a common directory structure and directory service configuration is used. The forest contains a single network configuration description and one schema catalog instance. A forest can consist of one or more domains. Within a forest, domains are linked by parent-child relationships. In this case, the name of the child domain necessarily includes the name of the parent domain.
Wood. Within the forest of a domain, the domain namespace contains the trees of the forest. Domains are interpreted as trees if one domain is a child of another. This means that the name of the root domain of the tree and all of its child domains need not contain the fully qualified name of the parent domain. A forest can contain one or more domain trees.
Website. A site is an Active Directory object such as a container that provides a piece of an enterprise with good network communication. Sites are usually used by businesses that have branches scattered throughout the country or across countries and even continents. The site creates a replication perimeter and uses Active Directory services. The main tasks of sites are to manage replication traffic and service localization. Replication refers to moving changes from one domain controller to another, and service localization allows users to authenticate to any domain controller in the entire site.
Installing the Active Directory Domain Services Role
For both GUI installation and command-line tools to create a domain controller, you must first install the Active Directory Domain Services role and then run the Domain Services Installation Wizard, which is opened with the Dcpromo.exe command. The example in this article will install a domain controller under Windows Server 2008 R2 in full installation mode, although the process itself is no different from installing in kernel mode.
To install the Active Directory Domain Services role using the command line, use the Server Configuration Management Tool ServerManagerCmd. Before installing the Active Directory Domain Services role, make sure that your server has been renamed and that you have configured the machine's IPv4 address. Do the following:
Rice. 3. Installing the Domain Services role using PowerShell
Elevate Domain Services Domain Controller
To automatically install a domain controller using the command line, use the command Dcporomo with certain automatic installation options. About forty parameters are available for automatic installation. In our case, we will not use parameters. Therefore, if you want to know all the options, run the command Dcpromo /?:Promotion. Consider the parameters that will be useful to us when installing a domain controller:
/NewDomain– this parameter defines the type of the created domain. Available options: Forest– the root domain of the new forest, tree– the root domain of a new tree in an existing forest, Child– a child domain in an existing forest;
/NewDomainDNSName– using this parameter, the full name of the new domain (FQDN) is specified;
/DomainNetBiosName– using this parameter, you can assign a NetBIOS name for the new domain;
/ForestLevel- Using this parameter, you can specify the forest functional mode when creating a new domain in a new forest. Available options: 0 – Windows 2000 Server native mode, 2 - Windows Server 2003 native mode, 3 - Windows Server 2008 native mode, 4 – Windows Server 2008 R2 native mode;
/ReplicaOrNewDomain- Specifies whether to install an additional domain controller or the first controller in the domain. Available options: Replica- an additional domain controller in an existing domain, ReadOnlyReplica- a read-only domain controller in an existing domain, domain- the first domain controller in the domain;
/DomainLevel- Specifies the domain functional level when creating a new domain in an existing forest, and the domain functional level cannot be lower than the forest functional level. The default is set to the same value as /ForestLevel;
/InstallDNS– using this parameter you can specify whether the domain name system will be installed for this domain;
/dnsOnNetwork– This parameter determines whether the DNS service is available on the network. This setting is used only if the network adapter of this computer is not configured with a DNS server name for name resolution. Meaning no means that a DNS server will be installed on this computer for name resolution. Otherwise, you must first configure the DNS server name for the network adapter.
/DatabasePath– using this parameter you can specify the full path (not in UNC format) to the directory on the fixed disk of the local computer where the domain database is stored. For example, C:WindowsNTDS;
/LogPath- with this option you can specify the full path (not in UNC format) to the directory on the fixed disk of the local computer containing the domain log files. For example, C:WindowsNTDS;
/SysVolPath- using this parameter, you can specify the full path (not in UNC format) to a directory on a fixed disk of the local computer, for example, C: WindowsSYSVOL;
/safeModeAdminPassword- Using this parameter, the password corresponding to the administrator name is specified, which is used to promote the role of a domain controller;
/RebootOnCompletion- This parameter specifies whether to restart the computer regardless of whether the operation was successful or not. Options available: Yes And no.
As a result, to install a domain controller, we will use the following command:
Dcpromo /unattend /InstallDNS:Yes /dnsOnNetwork:Yes /ReplicaOrNewDomain:Domain /NewDomain:Forest /NewDomainDNSName:testdomain.com /DomainNetBiosName:testdomain /DatabasePath:"C:WindowsNTDS" /LogPath:"C:WindowsNTDS" /SysvolPath:"C :WindowsSYSVOL” /safeModeAdminPassword: [email protected]/ForestLevel:4 /DomainLevel:4 /RebootOnCompletion:No
Rice. 4. Installing a domain controller
Conclusion
In this article, you learned about Active Directory Domain Services technology, learned about the meaning of terms such as domain controller, domain, forest, tree, and site. This article details the process of installing the Domain Services role and a domain controller using the ServerManagerCmd and Dcpromo.exe command-line utilities. Step-by-step guidance for installing the Active Directory Domain Services role using the ServerManagerCmd server configuration management tool and a PowerShell cmdlet is provided.
In this note, we will consider in detail the process of introducing the first domain controller in the enterprise. And there will be three of them:
1) Primary domain controller, OS - Windows Server 2012 R2 with GUI, network name: dc1.
Select the default option, click Next. Then select the default protocol IPv4 and click Next again.
On the next screen, set the network ID (Network ID). In our case, 192.168.0. In the Reverse Lookup Zone Name field, we will see how the address of the reverse lookup zone is automatically substituted. Click Next.
On the Dynamic Update screen, we will select one of the three possible dynamic update options.
Allow Only Secure Dynamic Updates. This option is only available if the zone is Active Directory integrated.
Allow Both Nonsecure And Secure Dynamic Updates. This switch allows any client to update its DNS resource records when there are changes.
Deny dynamic updates (Do Not Allow Dynamic Updates). This option disables dynamic DNS updates. It should only be used if the zone is not integrated with Active Directory.
Select the first option, click Next and complete the configuration by clicking Finish.
Another useful option that is usually configured in DNS is forwarders or Forwarders, the main purpose of which is to cache and redirect DNS requests from a local DNS server to an external DNS server on the Internet, for example, the one located at the ISP. For example, we want local computers in our domain network that have a DNS server (192.168. . To configure forwarders (Forwarders), go to the DNS manager console. Then, in the server properties, go to the Forwarders tab and click Edit there.
Specify at least one IP address. Several are desirable. We press OK.
Now let's configure the DHCP service. Let's start the tool.
First, let's set the full working range of addresses from which addresses will be taken to issue to clients. Select Action\New Scope. The Add Area Wizard starts. Set the name of the area.
Next, specify the start and end address of the network range.
Next, add the addresses that we want to exclude from the issuance of customers. Click Next.
On the Lease Duration screen, specify a non-default lease time, if required. Click Next.
Then we agree that we want to configure DHCP options: Yes, I want to configure these option now.
We will sequentially indicate the gateway, domain name, DNS addresses, WINS skip and at the end we agree with the activation of the scope by clicking: Yes, I want to activate this scope now. Finish.
For the DHCP service to work securely, a special account must be configured to dynamically update DNS records. This must be done, on the one hand, in order to prevent dynamic registration of clients in DNS using the domain administrative account and its possible abuse, on the other hand, in the event of a DHCP service reservation and a failure of the main server, it will be possible to transfer the zone backup to the second server , which will require the account of the first server. To fulfill these conditions, in the Active Directory Users and Computers snap-in, we will create an account named dhcp and assign an indefinite password by selecting the option: Password Never Expires.
Assign a strong password to the user and add it to the DnsUpdateProxy group. Then we remove the user from the Domain Users group, after assigning the primary user the DnsUpdateProxy group. This account will be solely responsible for dynamically updating records and will not have access to any other resources where basic domain rights are sufficient.
Click Apply and then OK. Open the DHCP console again. Go to the properties of the IPv4 protocol on the Advanced tab.
Click Credentials and specify our DHCP user there.
Click OK and restart the service.
We'll come back to configuring DHCP later when we're configuring DHCP service reservations, but to do that, we need to elevate at least the domain controllers as well.
UPD: I created a video channel on youtube where I gradually post training videos in all areas of IT that I am well versed in, subscribe: http://www.youtube.com/user/itsemaev
UPD2: Microsoft traditionally changes the familiar syntax on the command line, so the roles in each version of Windows Server may sound different. They are no longer called fsmo at all, but operation masters. So, for the correct commands in the console after fsmo maintenance, simply write? and it will show you the available commands.
They took an article from me in the April magazine "System Administrator" on the topic "Painless replacement of an obsolete or failed domain controller based on Windows Server"
And they even paid a hundred dollars and gave me a package with brains)) I'm now Onotole.
Painless replacement for an outdated or failed Windows Server-based domain controller.(who suddenly need - send pictures)
If your domain controller is out of order or completely outdated and needs to be replaced - do not rush to plan to spend the next weekend creating a new domain on a new server and painstakingly transferring user machines to it. Properly managing a backup domain controller will help you quickly and painlessly replace the previous server.
Almost every administrator working with Windows-based servers, sooner or later, is faced with the need to replace a completely outdated primary domain controller, the further upgrade of which no longer makes sense, with a new and more modern one. There are even worse situations - the domain controller simply becomes unusable due to breakdowns at the physical level, and backups and images are outdated or lost
In principle, a description of the procedure for replacing one domain controller with another can be found on various forums, but the information is given in fragments and, as a rule, is applicable only to a specific situation, but does not give an actual solution. In addition, even after reading plenty of forums, knowledge bases and other resources in English, I was able to competently carry out the procedure for replacing a domain controller without errors only from the third or fourth time.
Thus, I want to give a step-by-step instruction for replacing a domain controller, regardless of whether it is operational or not. The only difference is that with a “fallen” controller, this article will only help if you have taken care in advance and deployed a backup domain controller.
Preparing servers for promotion/demotion
The very procedure for creating a backup domain controller is elementary - we simply run the dcpromo wizard on any network server. Using the dcpromo wizard, we create a domain controller in an existing domain. As a result of the manipulations done, we get a deployed AD directory service on our additional server (I will call it pserver, and the main controller will be dcserver).
Further, if dcpromo did not offer it himself, we start the installation of the DNS server. You do not need to change any settings, you also do not need to create a zone - it is stored in AD, and all records are automatically replicated to the backup controller. Attention - the main zone in DNS will appear only after replication, to speed up which the server can be restarted. In the TCP / IP settings of the network card of the backup domain controller, the address of the primary DNS server must be set to the IP address of the primary domain controller.
Now you can easily check the health of the standby domain controller pserver. We can create a domain user on both the primary and backup domain controllers. Immediately after creation, it appears on the duplicate server, but for about a minute (while replication is taking place) it is shown as disabled, after which it starts to be displayed the same way on both controllers.
At first glance, all the steps to create a working scheme for the interaction of several domain controllers have been completed, and now, in the event of a failure of the "primary" domain controller, the "backup" controllers will automatically perform its functions. However, while the difference between "primary" and "backup" domain controllers is purely nominal, the "primary" domain controller has a number of features (FSMO roles) that should be kept in mind. Thus, the above operations for the normal functioning of the directory service in the event of a failure of the "primary" domain controller are not enough, and the actions that must be taken to correctly transfer / seize the role of the primary domain controller will be described below.
A bit of theory
You need to be aware that Active Directory domain controllers perform several kinds of roles. These roles are called FSMO (Flexible single-master operations):
- Schema Master (Scheme Master) - the role is responsible for the ability to change the schema - for example, deploying an Exchange server or ISA server. If the role owner is unavailable, you will not be able to change the schema of an existing domain;
- Domain Naming Master - This role is required if your domain forest has multiple domains or subdomains. Without it, it will not be possible to create and delete domains in a single domain forest;
- Relative ID Master (Master of relative identifiers) - is responsible for creating a unique ID for each AD object;
- Primary Domain Controller Emulator (Primary Domain Controller Emulator) - it is he who is responsible for working with user accounts and security policy. The lack of communication with it allows you to enter workstations with the old password, which cannot be changed if the domain controller has "fallen";
- Infrastructure Master (Infrastructure Master) - the role is responsible for the transfer of information about AD objects to other domain controllers within the entire forest.
These roles are written about in some detail in many knowledge bases, but the main role is almost always forgotten - this is the role of the Global Catalog (Global Catalog). In fact, this directory simply starts the LDAP service on port 3268, but its inaccessibility will prevent domain users from logging in. Remarkably, all domain controllers can have the global catalog role at the same time.
In fact, we can conclude - if you have a primitive domain for 30-50 machines, without an extended infrastructure, which does not include subdomains - then you may not notice the lack of access to the owner / owners of the first two roles. In addition, several times I came across organizations that have been operating for more than a year without a domain controller at all, but in a domain infrastructure. That is, all rights were distributed a long time ago, with a working domain controller, and did not need to be changed, users did not change their passwords and worked quietly.
Determine current fsmo role owners.
I clarify - we competently want to replace the domain controller without losing any of its capabilities. In the event that there are two or more controllers in the domain, we need to find out who owns each of the fsmo roles. This is easy enough to do using the following commands:
dsquery server -hasfsmo schema
dsquery server - hasfsmo name
dsquery server - hasfsmo rid
dsquery server - hasfsmo pdc
dsquery server - hasfsmo infr
dsquery server -forest -isgc
Each of the commands displays information about who owns the requested role (Fig. 1). In our case, the owner of all roles is the primary domain controller dcserver.
Voluntary transfer of fsmo roles using Active Directory consoles.
We have all the information necessary to transfer the role of the primary domain controller. Let's get started: first we need to make sure that our account is a member of the "Domain Admins", "Schema Admins" and "Enterprise Admins" groups, and then proceed with the traditional method of transferring fsmo roles - domain management through the Active Directory consoles.
To transfer the “domain naming master” role, perform the following steps:
- open "Active Directory Domains and Trust" on the domain controller from which we want to transfer the role. If we are working with AD on the domain controller to which we want to transfer the role, then we skip the next item;
- right-click on the Active Directory - Domains and Trusts icon and select Connect to a domain controller. We select the domain controller to which we want to transfer the role;
- right-click the Active Directory component - domains and trusts and select the Operations Masters command;
- in the Change Operations Master dialog box, click the Change button (Fig. 2).
- after an affirmative answer to the pop-up request, we get a successfully transferred role.
Similarly, using the Active Directory Users and Computers console, you can transfer the RID Master, PDC, and Infrastructure Master roles.
To transfer the "schema master" role, you must first register the Active Directory schema management library in the system:
After all the roles have been transferred, it remains to deal with the remaining option - the custodian of the global catalog. We go into Active Directory: “Sites and Services”, the default site, servers, find the domain controller that has become the main one, and in the properties of its NTDS settings, check the box next to the global catalog. (Fig. 3)
Bottom line - we changed the owners of roles for our domain. Who needs to finally get rid of the old domain controller - we lower it to a member server. However, the simplicity of the actions taken is compensated by the fact that their implementation in a number of situations is impossible, or ends in an error. In these cases, ntdsutil.exe will help us.
Voluntary transfer of fsmo roles using ntdsutil.exe consoles.
In case the transfer of fsmo roles using the AD consoles fails, Microsoft has created a very handy utility - ntdsutil.exe - an Active Directory directory maintenance program. This tool allows you to perform extremely useful actions - up to restoring the entire AD database from a backup that this utility itself created during the last change in AD. All its features can be found in the Microsoft Knowledge Base (Article ID: 255504). In this case, we are talking about the fact that the ntdsutil.exe utility allows both transferring roles and “selecting” them.
If we want to transfer a role from an existing “primary” domain controller to a “backup” one, we log into the system on the “primary” controller and start transferring roles (transfer command).
If for some reason we don’t have a primary domain controller, or we can’t log in under an administrative account, we log in to the backup domain controller and start “selecting” roles (the seize command).
So the first case - the main domain controller exists and functions normally. Then we go to the primary domain controller and type the following commands:
ntdsutil.exe
roles
connections
connect to server server_name (the one we want to give the role to)
q
If errors pop up, you need to check the connection with the domain controller to which we are trying to connect. If there are no errors, then we have successfully connected to the specified domain controller with the rights of the user on whose behalf we enter commands.
A full list of commands is available after querying fsmo maintenance with the standard sign? . It's time to hand over the roles. I immediately, without hesitation, decided to transfer the roles in the order in which they are specified in the instructions for ntdsutil and came to the conclusion that I could not transfer the role of the infrastructure master. To me, in response to a request to transfer a role, an error was returned: "it is impossible to contact the current owner of the fsmo role." I searched for information on the net for a long time and found that most people who get to the stage of transferring roles encounter this error. Some of them try to take this role forcibly (does not come out), some leave everything as it is - and live happily without this role.
I found out through trial and error that when transferring roles in this order, the correct completion of all steps is guaranteed:
- owner of identifiers;
- owner of the scheme;
- the owner of the naming;
- the owner of the infrastructure;
- domain controller;
After successfully connecting to the server, we receive an invitation to role management (fsmo maintenance), and we can start transferring roles:
- transfer domain naming master
- transfer infrastructure master
- transfer rid master
- transfer schema master
- transfer pdc master
After executing each command, a request should appear asking if we really want to transfer the specified role to the specified server. The result of successful execution of the command is shown in Figure 4.
The role of the global catalog keeper is transferred in the manner described in the previous section.
Forced assignment of fsmo roles using ntdsutil.exe.
The second case - we want to assign the role of primary to our backup domain controller. In this case, nothing changes - the only difference is that we carry out all operations using the seize command, but already on the server to which we want to transfer roles for assigning a role.
seize domain naming master
seize infrastructure master
seize rid master
seize schema master
seize pdc
Please note that if you took away a role from a domain controller that is currently absent, then when it appears on the network, the controllers will begin to conflict, and you cannot avoid problems in the functioning of the domain.
Work on bugs.
The most important thing that should not be forgotten is that the new primary domain controller will not fix the TCP / IP settings for itself: it is now desirable for it to specify 127.0.
At the same time, if you have a DHCP server on your network, then you need to force it to issue the ip address of your new server with the address of the primary DNS server, if there is no DHCP, go through all the machines and manually assign this primary DNS to them. Alternatively, you can assign the same ip to the new domain controller as the old one had.
Now you need to check how everything works and get rid of the main errors. To do this, I suggest deleting all events on both controllers, saving logs to a folder with other backups, and rebooting all servers.
After enabling them, we carefully analyze all event logs for the fact of warnings and errors.
The most common warning after transferring roles to fsmo is the message that "msdtc cannot correctly process a domain controller promotion/demotion that has occurred."
The fix is simple: in the "Administration" menu we find "Services
components". There we expand "Component Services", "Computers", open the properties of the "My Computer" section, look for "MS DTC" there and click there "Security Settings". There we allow "Access to the DTC network" and press OK. The service will be restarted and the warning will disappear.
An example of an error is a message stating that the main DNS zone cannot be loaded, or the DNS server does not see the domain controller.
You can understand the problems of the functioning of the domain using the utility (Fig. 5):
You can install this utility from the original Windows 2003 disc from the /support/tools folder. The utility allows you to check the health of all services of the domain controller, each of its stages must end with the words successfully passed. If you get failed (most often these are connection or systemlog tests), then you can try to fix the error automatically:
dcdiag /v /fix
As a general rule, all DNS-related errors should go away. If not, we use the utility to check the status of all network services:
And its useful debugging tool:
netdiag /v /fix
If after that errors related to DNS remain, the easiest way is to remove all zones from it and create them manually. It's quite simple - the main thing is to create a primary zone by domain name, stored in Active Directory and replicated to all domain controllers on the network.
Another command will give more detailed information about DNS errors:
dcdiag /test:dns
At the end of the work done, it took me about 30 more minutes to find out the reason for the appearance of a number of warnings - I figured out time synchronization, archiving the global catalog and other things that I hadn’t gotten my hands on before. Now everything is working like clockwork - most importantly, don't forget to have a standby domain controller if you want to remove the old domain controller from the network.
As the saying goes "suddenly appeared out of nowhere .... ....", nothing foreshadowed trouble, but then the main domain controller began to fail, and while he was still breathing he decided to delegate the rights of the main domain to another.
To transfer the “domain naming master” role, perform the following steps:
After all the roles have been transferred, it remains to deal with the remaining option - the custodian of the global catalog. We go to Directory: “Sites and Services”, the default site, servers, find the domain controller that has become the main one, and in the properties of its NTDS settings, check the box next to the global catalog. (Fig. 3)
the result - we changed the owners of roles for our domain. Who needs to finally get rid of the old domain controller - we lower it to a member server. However, the simplicity of the actions taken is compensated by the fact that their implementation in a number of situations is impossible, or ends in an error. In these cases, ntdsutil.exe will help us.
Voluntary transfer of fsmo roles at ntdsutil.exe consoles.
In case the transfer of fsmo roles with AD consoles failed, I created a very convenient utility - ntdsutil.exe - for servicing the Directory directory. This tool allows you to perform extremely actions - up to the entire AD database from the backup that it itself created during the last change in AD. To get acquainted with all its possibilities in knowledge (Article code: 255504). In this case, we are talking about the fact that ntdsutil.exe allows you to both transfer roles and “select” them.
If we want to transfer a role from an existing “primary” domain controller to a “backup” one, we go to the “primary” controller and start transferring roles (command transfer).
If for some reason we don’t have a primary domain controller, or we can’t log in under an administrative account, we log in to a backup domain controller and start “selecting” roles (command seize).
So the case - the primary domain controller exists and is functioning normally. Then we go to the primary domain controller and type the following commands:
ntdsutil.exe
connect to server_name (the one we want to give the role to)
If errors pop up, we need to communicate with the domain controller to which we are trying to connect. If there are no errors, then we have successfully connected to the specified domain controller with the rights of the user on whose behalf we enter commands.
A complete list is available from the fsmo maintenance query with the standard sign? . It's time to hand over the roles. I immediately, without hesitation, decided to transfer the roles in the order in which they are specified in the instructions for ntdsutil and came to the conclusion that I could not transfer the role of the infrastructure master. To me, in response to a request to transfer a role, an error was returned: "it is impossible to contact the current owner of the fsmo role." I searched for information for a long time and found that most people who get to the role transfer stage encounter this error. Some of them try to take this role forcibly (does not come out), some leave everything as it is - and live happily without this role.
I found out through trial and error that when transferring roles in this order, the correct completion of all steps is guaranteed:
Owner of identifiers;
Schema owner;
naming master;
Infrastructure owner;
domain controller;
After a successful connection to the server, we receive an invitation to role management (fsmo maintenance), and we can start transferring roles:
- transfer domain naming master
Transfer infrastructure master
Transfer rid master
Transfer schema master
Transfer pdc master
After executing each one, a request should appear asking if we really want to transfer the specified role to the specified server. The result of successful execution is shown in (Fig. 4).
The role of the global catalog keeper is transferred in the manner described in the previous section.
Forcing fsmo roles on ntdsutil.exe.
The second case is that we want to assign the role of primary to our backup domain controller. In this case, nothing changes - the only difference is that we carry out all operations using seize, but already on the server to which we want to transfer roles for assigning a role.
seize naming master
seize infrastructure master
seize rid master
seize schema master
Please note that if you have taken away a role from a domain controller that is currently absent, then when it appears in the controllers, they will begin to conflict, and you cannot avoid problems in the functioning of the domain.
Work on bugs.
The most important thing that should not be forgotten is that the new primary domain controller will not fix TCP / IP itself: it is now desirable for it to specify 127.0. If you have a DHCP server, then you need to force it to issue the primary DNS ip address of your new server, if there is no DHCP, go through all the machines and manually assign this primary DNS to them. As an option, assign the same ip to the new domain controller as the old one had. Now you need to see how everything works and get rid of the main errors. To do this, I suggest deleting all events on both controllers, saving logs to a folder with other backups, and rebooting all servers. After enabling them, carefully all event logs for warnings and errors. that "msdtc cannot correctly process the promotion/demotion of a domain controller that has occurred." The fix is simple: in from the original
If errors related to DNS remain, just delete all zones from it and create them manually. It's quite simple - the main thing is to create a primary zone by the name of the domain, stored in and replicated to all domain controllers on the network.
Another command will give more detailed information about DNS errors:
dcdiag /test:dns
At the end of the work done, it took me about 30 more minutes to find out the reason for the appearance of a number of warnings - I figured out time synchronization, archiving the global catalog and other things that I hadn’t gotten my hands on before. Now everything is working like clockwork - most importantly, do not forget to have a backup domain controller if you want to remove the old domain controller from the network.
