How to replace a domain controller and not break the current infrastructure
It so happened in our organization that the infrastructure had to be done quickly, and it took time to purchase licenses. Therefore, it was decided to use the images of Windows Server 2012R2 Evaluation, and after the test period it was already licensed. No one knew then that it was impossible to simply take the Standard license in the Evaluation release, and get the Standard license at the output, otherwise, I think, I would have bought the licenses first. But there is nothing to do, what we have, so we work. So.
Task: after buying Microsoft licenses on Windows server 2012R2 Standard, you need to activate them on our servers. Getting started.
A problem was encountered while performing the task. Since we initially installed the Windows server 2012R2 Standard Evaluation, when trying to register a key for Standard, the server says that this key does not suit it. Began to search for a solution to the problem of transferring the server from the Evaluation version to the Standard. The answer was found on the Microsoft website in a TechNet article.
Partly article helped solve the problem. We were able to change the version on three physical servers and activate them with our licenses. But, unfortunately, not everything was so easy with the domain controllers. The above article directly states that domain controllers are IMPOSSIBLE to be transferred from the Evaluation issue to Standard. We need to do this as soon as possible, because the number of possible / rearm for the PDC is over, and there are less than 3 days left until the end of the trial version.
')
I saw two options for resolving the issue. Or, alternately between BDC and PDC, transfer the rights of the schema master and other roles, downgraded to member servers and then back up. But I dismissed the idea of this domain volleyball, for the reason that I simply did all this for the first time and was afraid to break it.
Therefore, it was decided to raise the new server, upgrade to the domain controller and transfer the schema master to it, and then turn off the old PDC and assign its new IP, then this option seemed easier and safer to me. I note that after the events described below, I still think this is a good solution, at least everything went without incident, otherwise the article would have a completely different title, or it would not exist at all.
The scheme can be reproduced without problems during the working day. It remained a day and a half, so I had no time to dream about how I would do all this, I had to start it urgently. Further actions on points.
1. Create a new virtual machine with the parameters corresponding to the current PDC. It is desirable to create on a physical server on which there are no other domain controllers, but this is if you have several hypervisors, as in my case, if not, then it doesn’t matter, only the fault tolerance. Well, if you work not with hypervisors, but with real servers, then the PDC and BDC fault tolerance is a matter of course.
2. Install Windows Server 2012R2. Select the Standard release with a graphical interface. Configure TCP / IP and rename the server in accordance with the standard names in the IT infrastructure.
3. After installation in the server manager, we include new roles to the server. We are interested in AD, DNS and other roles and components used on current domain controllers.
4. We raise the server to the domain controller. Replication takes place between the main domain controller and the new one.
5. We transfer the role of the schema master from the old DC to the new one.
To do this, go to the domain controller, which will be assigned the role of FSMO, run the command line, and enter commands in the following sequence:
ntdsutil
roles
connections
connect to server <PDC server name>
q
Having successfully connected to the server, we will receive an invitation to role management (FSMO maintenance), and we can proceed to the transfer of roles:
transfer naming master - transfer the role of the host of domain names.
transfer infrastructure master - transfer of the infrastructure master role;
transfer rid master - transfer of the role of the host RID;
transfer schema master - transfer of the schema master role;
transfer pdc - transfer the role of the PDC emulator
To terminate Ntdsutil, enter the command q.
6. After the transfer of the schema master, we look at the system log and dcdiag for errors. They should not be. If there is, correct. (I encountered a dns error where the server complained about incorrectly specified forwarders. On the same day, I learned that the DNS forwarders should not indicate the server on which the DNS is installed (usually indicate the DNS server of the provider and Yandex (Google), which in general is logical, it essentially creates a loop in the DNS.
7. If errors are corrected, or they are not. Getting down to changing IP addresses. We assign to the old PDC any free IP address on the network, and to the new PDC we assign the address of the old one.
8. Check for errors again. We carry out tests. Turn off the old PDC and BDC. We check the possibility of authorization in the domain. Then we leave only BDC turned on; we check if it assumes the role of a domain controller in the event of a PDC being unavailable.
9. If all tests pass successfully. You can destroy the old PDC and start changing the BDC version.
10. In our case, the old PDC still could not be thrown into the dustbin as the DFS namespace functioned on it, and we did not know how to replicate it to the new server.
11. Everything turned out to be very simple. Enter the graphical tooling "DFS Management". In the "Namespace" we add existing namespaces, then we add a namespace server and in general everything to each namespace. The root dfs automatically appears on c: \ along with links to network resources and everything works. Just in case, we check the work by turning off the old PDC. At first, network resources will be unavailable (DFS needs 300 seconds to replicate). After 5 minutes, network resources should become available again.
12. We leave the old PDC off and after some time down to the member server and then delete. You can of course and immediately, but I was scared and until recently I did not believe that everything turned out without problems.
PS: All the above actions were carried out after a careful study of the book Windows server 2012R2 - Complete Guide. In particular, the chapters devoted specifically to AD, DNS and DFS, as well as domain controllers. Without understanding and planning, it is better not to start these actions, since You can lose the working infrastructure.
I hope for someone this article will be useful and necessary. Thanks for attention!
Task: after buying Microsoft licenses on Windows server 2012R2 Standard, you need to activate them on our servers. Getting started.
A problem was encountered while performing the task. Since we initially installed the Windows server 2012R2 Standard Evaluation, when trying to register a key for Standard, the server says that this key does not suit it. Began to search for a solution to the problem of transferring the server from the Evaluation version to the Standard. The answer was found on the Microsoft website in a TechNet article.
Partly article helped solve the problem. We were able to change the version on three physical servers and activate them with our licenses. But, unfortunately, not everything was so easy with the domain controllers. The above article directly states that domain controllers are IMPOSSIBLE to be transferred from the Evaluation issue to Standard. We need to do this as soon as possible, because the number of possible / rearm for the PDC is over, and there are less than 3 days left until the end of the trial version.
')
I saw two options for resolving the issue. Or, alternately between BDC and PDC, transfer the rights of the schema master and other roles, downgraded to member servers and then back up. But I dismissed the idea of this domain volleyball, for the reason that I simply did all this for the first time and was afraid to break it.
Therefore, it was decided to raise the new server, upgrade to the domain controller and transfer the schema master to it, and then turn off the old PDC and assign its new IP, then this option seemed easier and safer to me. I note that after the events described below, I still think this is a good solution, at least everything went without incident, otherwise the article would have a completely different title, or it would not exist at all.
The scheme can be reproduced without problems during the working day. It remained a day and a half, so I had no time to dream about how I would do all this, I had to start it urgently. Further actions on points.
1. Create a new virtual machine with the parameters corresponding to the current PDC. It is desirable to create on a physical server on which there are no other domain controllers, but this is if you have several hypervisors, as in my case, if not, then it doesn’t matter, only the fault tolerance. Well, if you work not with hypervisors, but with real servers, then the PDC and BDC fault tolerance is a matter of course.
2. Install Windows Server 2012R2. Select the Standard release with a graphical interface. Configure TCP / IP and rename the server in accordance with the standard names in the IT infrastructure.
3. After installation in the server manager, we include new roles to the server. We are interested in AD, DNS and other roles and components used on current domain controllers.
4. We raise the server to the domain controller. Replication takes place between the main domain controller and the new one.
5. We transfer the role of the schema master from the old DC to the new one.
To do this, go to the domain controller, which will be assigned the role of FSMO, run the command line, and enter commands in the following sequence:
ntdsutil
roles
connections
connect to server <PDC server name>
q
Having successfully connected to the server, we will receive an invitation to role management (FSMO maintenance), and we can proceed to the transfer of roles:
transfer naming master - transfer the role of the host of domain names.
transfer infrastructure master - transfer of the infrastructure master role;
transfer rid master - transfer of the role of the host RID;
transfer schema master - transfer of the schema master role;
transfer pdc - transfer the role of the PDC emulator
To terminate Ntdsutil, enter the command q.
6. After the transfer of the schema master, we look at the system log and dcdiag for errors. They should not be. If there is, correct. (I encountered a dns error where the server complained about incorrectly specified forwarders. On the same day, I learned that the DNS forwarders should not indicate the server on which the DNS is installed (usually indicate the DNS server of the provider and Yandex (Google), which in general is logical, it essentially creates a loop in the DNS.
7. If errors are corrected, or they are not. Getting down to changing IP addresses. We assign to the old PDC any free IP address on the network, and to the new PDC we assign the address of the old one.
8. Check for errors again. We carry out tests. Turn off the old PDC and BDC. We check the possibility of authorization in the domain. Then we leave only BDC turned on; we check if it assumes the role of a domain controller in the event of a PDC being unavailable.
9. If all tests pass successfully. You can destroy the old PDC and start changing the BDC version.
10. In our case, the old PDC still could not be thrown into the dustbin as the DFS namespace functioned on it, and we did not know how to replicate it to the new server.
11. Everything turned out to be very simple. Enter the graphical tooling "DFS Management". In the "Namespace" we add existing namespaces, then we add a namespace server and in general everything to each namespace. The root dfs automatically appears on c: \ along with links to network resources and everything works. Just in case, we check the work by turning off the old PDC. At first, network resources will be unavailable (DFS needs 300 seconds to replicate). After 5 minutes, network resources should become available again.
12. We leave the old PDC off and after some time down to the member server and then delete. You can of course and immediately, but I was scared and until recently I did not believe that everything turned out without problems.
PS: All the above actions were carried out after a careful study of the book Windows server 2012R2 - Complete Guide. In particular, the chapters devoted specifically to AD, DNS and DFS, as well as domain controllers. Without understanding and planning, it is better not to start these actions, since You can lose the working infrastructure.
I hope for someone this article will be useful and necessary. Thanks for attention!
Source: https://habr.com/ru/post/273093/
All Articles