Team, I am posting some more Active directory question. These questions below are getting little more complicated than previous questions. I am also including feedback from Joe Nagy. Joe has been passing his knowledge to us and I wanted to share some of it with you all here.
Please pay attention to Joe's feedback there is so much to gain from his feedback if you pay attention.If you have any question, please post it here.
1. If full qualified domain name is Smtp25.org what would be the distinguish name
2. Which support tools are being used to troubleshoot the DNS issues?
3. What tools are you familiar with AD General Heath Check?
4. What port Kerberos uses and what is Kerberos
5. What is KCC, and Explain bi-directional ring with extra edges?
6. Explain Journal Wrap, how it happens and how can it be fixed
7. What is default DNS Type code on SRV RESOURCE?
8. Explain lingered object and how to trouble shoot the issues related to it
- This is to see if they know LDAP. In order to work with LDAP and AD, LDAP has to "bind" to specific object in AD before doing any operations. All 'binds' are done with distinguished names.
- 2003 support tools added DNS tests to DCDIAG that the 2000 tools don't have. Also for general connectivity/DNS testing Netdiag is very helpful. Plus...there's dnscmd, dnslint..... and of course network monitor captures.... I use Ethereal
- Anyone who's had to troubleshoot a DC ought to know that DCDIAG /v is almost always the first place to go
- (Question 4&5) Port 88 UDP and TCP. Kerberos Version 5 is standard on all versions of Windows 2000 and later plus ensures the highest level of security to network resources. The Kerberos protocol name is based on the three- headed dog figure from Greek mythology known as Kerberos. The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired service to access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). Kerberos is totally different beast than LM/NTLM. You get tickets instead of contently doing 'challenge/response'. BUT, in an environment you will never ONLY use Kerberos. For things like non-interactive logins(OWA), cross domain SMB access, and many other instances you will fall back to NTLM (v2 if you're setup to not use v1 or LM which are security risks as they store hashes on the servers that can be cracked)
- NTFS maintains a special log called the NTFS USN journal, which is a high-level description of all the changes to files and directories on an NTFS volume. FRS uses this mechanism in order to track changes to NTFS directories of interest, and to queue those changes for replication to other computers. The NTFS USN journal has defined size limits and will discard old log information on a first-in, first-out basis in order to maintain its correct size.
- If FRS processing falls behind the NTFS USN journal, and if NTFS USN journal information that FRS needed has been discarded, then FRS enters a journal wrap condition. FRS then needs to rebuild its current replication state with respect to NTFS and other replication partners.
- Resolution: To perform a nonauthoritative restore, stop the FRS service, configure the BurFlags registry key, and then restart the FRS service. To do so:
1. Click Start, and then click Run.
2. In the Open box, type cmd and then press ENTER.
3. In the Command box, type net stop ntfrs.
4. Click Start, and then click Run.
5. In the Open box, type regedit and then press ENTER.
6. Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
7. In the right pane, double-click BurFlags.
8. In the Edit DWORD Value dialog box, type D2 and then click OK.
9. Quit Registry Editor, and then switch to the Command box.
10. In the Command box, type net start ntfrs.
11. Quit the Command box.
When the FRS service restarts, the following actions occur:
The value for BurFlags registry key returns to 0.
Files in the reinitialized FRS folders are moved to a Pre-existing folder.
An event 13565 is logged to signal that a nonauthoritative restore is started.
The FRS database is rebuilt.
The member performs an initial join of the replica set from an upstream partner or from the
computer that is specified in the Replica Set Parent registry key if a parent has been specified for
SYSVOL replica sets.
The reinitialized computer runs a full replication of the affected replica sets when the relevant
Replication schedule begins.
When the process is complete, an event 13516 is logged to signal that FRS is operational. If the
event is not logged, there is a problem with the FRS configuration.
- LingeringObjects are introduced by DCs/GCs that have been offline or failed to replicate for the tombstone lifetime. Say that DC A and B are online. B goes offline. 10 users get deleted from A. The 10 users remain in deleted items for 60 days or whatever its set to. (Tombstone lifetime). If you bring B back up any time before the 60 days are up, no problem. During replication, B would move the users to deleted items just as on A. But, if its brought up AFTER, those deleted users aren't in the A database at all, anywhere so B knows they aren't on A but has no way of knowing what happened to them. So they remain in B's database as lingeringobjects. Most places use strictreplication consistency to avoid replicating the objects around which could cause problems.
2.Click Add Value on the Edit menu.
3.Add the following value:
Value Name: Strict Replication Consistency
Data type: REG_DWORD
Value data: If the value is 1 it is enabled and lingeringobjects won't replicate.
Lingering objects may be a problem in the following scenarios:
•The lingering object is holding a value on a unique attribute, such as samAccountName, that another object wants to use.
•The lingering object is a security risk, for example, it may represent a user that you should have deleted.
•The lingering object only exists in the read-only naming context (global catalog). This behavior makes the object difficult to delete.
If you enable Strict Replication Consistency, a destination stops replicating and you receive the error message that is described in the "Symptoms" section of this article if the destination receives modifications for an object that it does not have. Typically, this problem occurs when a good domain controller that does not have the object replicates in a change to a lingering object from a bad source that has been out of contact.
- If you enable Loose Replication Consistency, if a destination receives a change to an object that it does not have, the entire object is replicated to the target for the sake of replication consistency. This behavior causes a lingering object to be reapplied to all domain controllers in the replication topology.
- TO REMOVE: 2003 support tools Repadmin has a /removelingeringobjects switch that helps. 2000 is much more difficult, especially in they are in the GC partions that are READ ONLY. You can't delete from READ ONLY. This is where an "operational" attribute comes into play. Progamatically, at RootDSE, an operational attribute called 'removelingeringobject' with info about the object is written. You're essentially telling AD to delete it for you since its read only and you can't.