If there are problems in active directory, these usually manifest themselves in the fact that users can no longer log on, domains and other objects cannot be added, data cannot be accessed or system services crash. The problem here is to narrow it down and then solve it. The following procedure helps.
Step 1: test name resolution
If problems occur in Active Directory, it is often because the name resolution between different components does not work. These can be problems between domain controllers , but also problems with name resolution between servers, workstations and domain controllers. To rule this out, the name resolution should first be tested between the servers involved.
With “nslookup” you can quickly check whether the name of servers can be resolved and whether the domain controllers can be resolved among themselves. For this, ” nslookup <server name> is entered. These tests quickly find out where there are problems with name resolution.
Sometimes it can happen that the entries of Active Directory no longer work correctly. This can be remedied with on-board means. With “net stop netlogon” and “net start netlogon”, for example, the login service can be restarted on domain controllers. The service tries to register the data of the file “netlogon.dns” from the folder “\ Windows \ System32 \ config \ netlogon.dns” again in DNS . If there are any problems, there are entries in the event log under “System” of the service, which help to solve the problem.
The “nltest / dsregdns” command also often helps with problems with DNS registration. If the re-registration does not work by restarting the login service, the DNS zone “_msdcs” and the created delegation can be deleted as a test. However, this should only be the last measure. The next time the login service starts, it reads the data from “netlogon.dns”, creates the zone “_msdcs” and writes the entries back into the zone.
Step 2: test connection with ping
If the name resolution works between the computers, the next thing to do is to “ping” to see whether a network connection can be established between the servers involved and the domain controllers. The connection must also work between the domain controllers. Typically, ICMP traffic is allowed between computers in domains. If a ping response does not work, you should first test whether the ICMP traffic is blocked at any point on the network. More info Laptop Repairs in Canberra
Step 3: diagnose the domain controller
If name resolution and ping work between the servers and domain controllers involved, the next step is to run a diagnosis locally on the server with “dcdiag / v”. If domain controllers show errors here, they can be researched on the Internet, which causes the errors. Ideally, dcdiag should be used locally on each domain controller to limit errors.
Focus on Active Directory
Step 4: test replication
With “repadmin / showreps” the replication connections between the different domain controllers can be tested. By entering the command you can quickly see which domain controllers have problems with replication among themselves. This diagnosis should review all domain controllers that are included as a replication connection in the Active Directory and Services snap-in.
“Nltest / dsgetsite” can be used to check whether domain controllers are in the right location and to recognize this location. Nltest can also help to display a list of all domain controllers: “nltest / dclist: <NetBIOS DOMAIN NAME>”. The list should be checked for completeness.
Step 5: Check Event Viewer
In the event viewer of Windows servers, errors can be found above all in the “System” log, which also affect Active Directory. Using the context menu of the log, the entries can be filtered for errors so that only the relevant errors are displayed. This provides a quick overview of which servers are experiencing errors. At the same time, the other event displays can also be checked to see whether errors have also occurred there. This can often tell where problems are caused.
Step 6: check permissions
Errors in Active Directory can also lead to problems with permissions. In this case it should be checked whether the corresponding user is also a member of the correct groups. Memberships of administrators should also be checked. There are various admin groups in Active Directory. General rights in the domain are only available to users who are in the “Domain Admins” group, changes to the schema may only be made by “Schema Admins”, and adjustments to higher-level areas in Active Directory may only be made by “Organization Admins” be made.
Step 7: test FSMO roles
If errors occur in Active Directory, it can happen that the FSMO roles no longer work or are not assigned correctly. Here it should be checked for each operations master on which domain controller it is positioned and whether the corresponding domain controller can be reached in the network.
If, for example, the PDC master does not work, problems arise when using group policies, the RID master is responsible for the fact that new objects can be created in Active Directory. The DNS master ensures that new domains are added to Active Directory, and the schema master enables the schema to be expanded. The infrastructure master provides group memberships between domains in Active Directory.
The FSMO role holders can be shown bundled with “netdom query fsmo”, or individually using the commands:
dsquery server -hasfsmo pdc (PDC master)
dsquery server -hasfsmo rid (RID master)
dsquery server -hasfsmo infr (infrastructure master)
dsquery server -hasfsmo schema (schema master)
dsquery server -hasfsmo name (domain name master)
Source website https://canberracomputerrepairs.com.au/