Thank you for Guido Grillenmeier's article "Leverage LVR to Simplify AD Object Recovery" (August 2007, InstantDoc ID 96310). Guido deepened my understanding of Active Directory (AD) and how it replicates. I might have to read the article a couple of times to fully understand everything, though.
As I was reviewing my AD groups to see if they contain Linked Value Replication (LVR) links, I ran into an interesting find with the default group Domain Users, which most of our users have as their primary group. When I run the command
it returns information only about the users who do not have Domain Users set as their primary group. If I go into an individual user account and change the primary user group, the individual shows up when I rerun the command.
• Why don't user accounts show up when their group is set to primary?
• Since I can't see the LEGACY, ABSENT, or PRESENT status for the users, can I assume that all the LVR links are PRESENT?
I'm glad you liked the article. The topic is fairly complex.
The Domain Users group is a special group just like Domain Computers and a few others in AD. As you noted, those groups' membership is typically not explicit by virtue of the user (or computer) being listed in the group's memberOf attribute. Instead, the member's PrimaryGroupID attribute is populated with the Relative Identifier (RID) of the respective AD group (513 for Domain Users). This attribute is indexed so that the OS can list all members quickly.
The Active Directory Users and Computers GUI fools you by displaying the users as normal members of the Domain Users group. When you check the memberOf tab for a user, it also displays the Domain Users group. The GUI basically checks both the backlinks and the PrimaryGroupID, just like the logon process does to add the group to a user's token. This process allows an AD domain to contain as many users (or computers) as you want and not be limited by the number of members or forward links that could fit into a group's member Of attribute.
When you change a user's primary group, the same logic is applied to the other group: The user's link is removed and instead the group's RID is written to the user's PrimaryGroupID attribute. But because you didn't remove the Domain Users group when you edited the user's PrimaryGroup, an explicit link is added to the Domain Users group.
So basically, a group that's populated with the PrimaryGroup feature doesn't
use LVR. However, it works similarly in that it allows very large groups and
only the membership change is replicated.
I just read "Leverage to Simplify AD Object Recovery" and liked it a lot. I
hope more people will buy into taking LVR and the related issues more seriously
once they or some of their staff have read the article.
Dan Gillard's article "Automate the Windows 2003 Defragmenter Without Paying Extra" (Reader to Reader, May 2007, InstantDoc ID 95487) made me wonder: Why not just use defrag.exe, which is a command-line tool that ships with Windows Server 2003 and Windows XP and can be easily scheduled with Task Scheduler? Does it offer less functionality than dfrgntfs.exe?
The batch file uses defrag.exe to launch dfrgntfs.exe. I don't use defrag .exe directly with the Task Scheduler because this process runs on a file server, and usually no one is logged on to the server. For a scheduled task to work when no one is logged on, you need a username and password that has admin rights to run the task. For all I know there might be a way to hack into the task scheduler to get passwords, and I'd rather not have that.
Instead of having a process run by a user who has admin rights on the server, I use the AT command to run the command like a service without a logon account. This approach also runs the process in the background and prevents windows from popping up.
The log file this batch file creates also is a good way to check for problems after the defrag process has run. Defrag .exe itself doesn't create a log unless you output the process to a text file.
The batch file I created is just another means to defrag the system, with
Mysterious Behavior of the Windows Indexing Service
Thank you Bret Bennett for sharing in detail what you learned about the Windows Indexing Service ("An Unlikely Culprit Can Cause Computers to Hang," August 2007, InstantDoc ID 96343), and thank you Windows IT Pro for printing it. That article is a good example of why I subscribe to the magazine.