Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to restore the active directory root domain in the multi-domain forest, which has a certain reference value. Interested friends can refer to it. I hope you will gain a lot after reading this article. Let the editor take you to know about it.

I recently dealt with a situation where the entire forest root domain needs to be restored. The structure itself is relatively simple, including two domains, an empty forest root, and a subdomain that includes all users, computers, and so on. There are only about 4000 users.

But there are two (almost fatal) problems. First, the organization established only one domain controller in the root domain. Second, and more unfortunately, the domain controller has not been backed up for more than 10 months. Although the root domain controller is a RAID-5 disk configuration, on the same day, a disaster occurs and two of the drives are down.

This type of configuration may inherit a practice that Microsoft believed in in the early days of Windows 2000. The suggestion at that time was to create an empty root domain so that when the subdomain name was changed, it could be added or removed (you cannot rename a domain after it has been defined).

This approach does not continue, however, because multiple domain forests have other complexities: restoring back-end links between groups and users in a cross-domain group, latency objects in the read-only context of the global catalog server, and other related issues. In order to avoid these problems, some organizations have to split the multi-domain structure into a single domain.

In this example, the two domains are Corp.com and EMEA.Corp.com, where Corp-DC1 is the domain controller in the root domain, and EMEA-DC1 and EMEA-DC2 are the domain controllers in the subdomain.

Please note that all customers-- including users, workstations, and servers-- are not affected by this issue, which gives us time to specify and issue a processing plan.

Challenges

There are a number of problems and challenges in this situation, including:

I haven't seen an example of a forest root domain that needs to be restored, and I can't find anyone who has.

Restoring backups from 10 months ago introduces latency objects into the forest of well-functioning subdomain controllers

What problems do you encounter if you change the system time in the root domain controller when restoring a January backup?

Do you need to repair the trust relationship between the Corp.com and EMEA.corp.com domains? Similarly, do you need to reset the secure tunnel password?

Is it necessary to use an authorized backup?

What kind of replication problems do you encounter when restoring Corp.com January backups?

However, there are some positive factors in this disaster:

There are no users or workstations in the root domain-just administrative accounts and domain controllers. Therefore, there is little harm in delaying objects when restoring backups that are 10 months old.

No modifications have been made to the root domain controller (such as active Directory objects) (although you need to be concerned about changes to the configuration container)

The domain name server is delegated to the subdomain. Therefore, for the customer, the EMEA.corp.com is domain name independent and has no resources in the parent domain.

Recovery plan

The original idea was to restore the EMEA domain controller to the January backup, restore the Corp domain controller, forward roller domain controller, and then adjust to the current time. The 20-step process required downtime for several days and was rejected because of its complexity and destructiveness.

We * have adopted the following simpler plan:

Restore the current backup of the two sub-domain controllers (and the January backup of the root domain controller), turning the three domain controllers into three computers on a private network.

Solve the problem, and then repeat the steps to produce the forest.

Add a second domain controller to the Corp. com domain.

Back up all domain controllers in both domains.

The whole process took about 3 weeks, and most of the time was spent studying logs, restoring, and so on. We considered the process in detail and implemented it methodically to ensure that everything was done properly. In addition, the user will not encounter downtime. This means that although there is no root domain, the forest seems to be in jeopardy, and it works well for user authentication and our restore. Our production recovery is carried out during working hours without affecting users.

Recovery process

The recovery process includes the following steps:

1. Get three computers and configure them on a private subnet.

two。 Rebuild the status backup of the current system on EMEA-DC1 and EMEA-DC2 on the test computer.

3. Restore the January backup of Corp-DC1 to the test computer.

4. Set the system time on the January backup of Corp-DC1 to the current date / time.

5. Set the tombstone life to 365 (*) to eliminate the temporary delay object problem. Modify the tombstone lifetime attribute on cn=Directory Service,cn=WindowsNT,cn=Services,cn=Configuration and dc=pp through ADSIEdit

6. Set the registry key strict replication consistency (strict replication consistency) value to "1" (strict) to avoid delayed objects during replication.

HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/NTDS/ParametersValueName = Strict Replication ConsistencyData Type = Reg_DWORD Value Data = 1

7. Uncheck the global catalog parameters on Corp-DC1. Re-enable after the replication is complete.

8. Use HPSReports to perform a physical examination of the domain controller. Check for any errors one by one until all errors are cleaned up:

Netdom Trust/verfy to verify the trust relationship between the Corp and EMEA domains.

C: > netdom trust Corp / domain:EMEA.corp.com / verify

The trust between Corp and EMEA.corp.com has been successfully verified.

Repadmin/Replsum / bysrc / bydest / sort:delta to test replication of all domain controllers in the forest.

DCDiag / test:DNS / e / v to test DNS problems for all DNS NS in the forest.

All event logs.

Ensure that the application event log shows that 1704 (SCECLI) events in Group Policy (the Application event log indicating Group Policy) are applied. At the same time, check the GPResult output of each machine to see if the GPO is normal.

Make sure that you can log on to a computer in the EMEA domain through a Corp.com account-and vice versa-to further verify the trust relationship.

Add customers from the production EMEA domain to the test EMEA domain and see if it can be identified.

Add users and sites to the domain controllers in each domain and see if they can be replicated to all domain controllers. This tests the domain and configures NC replication.

9. When all the problems are solved, repeat these steps in the production forest.

10. After the production root domain controller (Corp-DC1) is restored, a second domain controller is set up in that domain (the second domain controller in the root domain prevents the initial problems).

11. Make scheduled backups of all four domain controllers.

twelve。 Reset the tombstone lifetime attribute to a minimum of 120 to 180 days. Ensure that the value of strict replication consistency (the strict replication consistency) is still 1.

Result

Initially, a large number of errors and warnings were displayed in the event log, as well as some errors in the Repadmin/showrepl report. Many of these errors occur as a result of attempts to repair the system. After running overnight, most of the bugs were fixed by themselves. We then deal with the remaining events until they are resolved. The test and production environments produced similar results.

1. There are some DNS issues because dynamic registration is not enabled. As a result, we had to configure some DNS records manually.

two。 After an initial restore of the Corp-DC1 domain controller for the root domain (from the old backup), you can find an event classification in the directory service event log, including:

1869-GC was found in Site-LAN (which means EMEA-DC1)

1655-GC cannot be found in one of the sites (referring to EMEA-DC)

Events 1869 and 1655 are logged in the order of EMEA and Corp-DC1 servers

Some 1311 events.

Some replications involving DNS lookup failures were unsuccessful

Many 1869 and 1865 events have encountered difficulties in finding global catalogs. Ignoring all these events, replication can still take place, as we can find by running Repadmin / replsum / bysrc / bydest / sort:delta:

3. Through the DCDiag / test:DNS / e / v report, we found that DNS was working as expected.

4. There are many W32 time events-event ID 29, 24, and 22-that do not require further action and will disappear over time.

5. After the old restored Corp-DC1 is put online, there will be a large number of warning and error events at first. After 12 hours, they were all repaired by themselves.

Overall, the restore went quite well and was relatively error-free. This is done without downtime and with minimal environmental risk. There is no need to use an authorized backup, and the trust relationship does not need to be repaired. Since we have tested it in the test environment, we are confident that we will put this plan into the production environment. Still, this is just a "this should work" assumption for you, and you can't really master it until you've tried it.

Thank you for reading this article carefully. I hope the article "how to restore the active directory root domain in the multi-domain forest" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.