Remediate Active Directory Members that Don't Support LVR

Doctor Scripto

Summary: Ian Farr talks about using Windows PowerShell to find and remediate Active Directory members that don’t support linked-value replication.

Microsoft Scripting Guy, Ed Wilson, is here. Today we welcome back Microsoft PFE, Ian Farr, as our guest blogger. To read more of Ian's previous guest posts, see these Hey, Scripting Guy! Blog posts. Ian has also started blogging at PoSh Chap. The keyboard is yours, Ian.

This post is a new take on an old challenge…

The final cut

Like one of my favorite films, Active Directory has stood the test of time. It’s grown over the years with new functionality, enhancing its incredible usefulness and also correcting a few limitations.

Photo of night sky

Today, I’m going to discuss an early limitation that was addressed between operating system versions. It’s a well-documented issue that requires administrative input to fully resolve. I’m going to show you how to eradicate any remnants of this limitation with the aid of the Active Directory Replication cmdlets that were introduced in Windows Server 2012. Today is about finding and remediating group members that don’t support linked-value replication (LVR).

“The smallest change that can be replicated in Windows 2000 Active Directory is an entire attribute; even if the attribute is linked and multivalued, all values replicate as a single change. The smallest change that can be replicated in Windows Server 2003 Active Directory is a separate value in a multivalued attribute that is linked. This Windows Server 2003 feature is called linked-value replication…”

Should you worry?

If your Active Directory forest was created when Windows Server 2000 was the latest and greatest operating system, you may have groups that still don’t utilize the LVR functionality introduced in Windows Server 2003. Why?

After your forest was upgraded to a forest functional level of Windows Server 2003 or Windows Server 2003 interim, any new members added to a group created in the Windows 2000 days would be seen as LVR compliant (PRESENT). However, any existing members of that group would not participate automatically in LVR, thereby preventing the group from efficiently replicating and maintaining a risk of data loss. These non-LVR group members are known as LEGACY.

Take a look at this sample output from the legendary repadmin tool:

Image of command output

Notice that the LEGACY member attributes don’t have any replication metadata reported.

The fix? After you know which groups have LEGACY members, convert those members from LEGACY to PRESENT by removing them from the group and then adding them back in. Enter our system administrator, armed only with guile and Windows PowerShell…

Do cmdlets dream about electric sheep?

You are a "PoSh Runner," a hunter of LEGACY group members. Once detected, LEGACYs are to be retired.

How do you detect groups with LEGACY members in your domain? You use the Voight-Kampff Windows PowerShell analyzer:

#List the groups that have legacy members

Get-ADGroup -Filter * -Server rootdc01.contoso.com |

Get-ADReplicationAttributeMetadata -Server rootdc01.contoso.com -Properties Member -ShowAllLinkedValues |

Where-Object {$_.Version -eq 0} | Select-Object @{n="Group";e={$_.Object}} -Unique

Here we get all of the groups from the target domain and pipe them to the Get-ADReplicationAttributeMetadata cmdlet. We’re interested in the metadata for the Member attribute, and we use the ShowAllLinkedValues parameter to ensure we get all the values associated with that attribute. Where-Object lets us filter on Member values that are LEGACY. A version number of 0 is the key here; it denotes that it’s not a replicated value. Finally, Select-Object gives us some custom output and further filters replica group distinguished names derived from the $_.Object properties. Here’s some sample output:

Image of command output

How do you get a list of all LEGACY members and their associated groups from your domain? That’s right, you use the Voight-Kampff Windows PowerShell analyzer:

#List all of the the legacy members and their associated group

Get-ADGroup -Filter * -Server rootdc01.contoso.com |

Get-ADReplicationAttributeMetadata -Server rootdc01.contoso.com -Properties Member -ShowAllLinkedValues |

Where-Object {$_.Version -eq 0} | Select-Object @{n="LEGACY";e={$_.AttributeValue}},@{n="Group";e={$_.Object}}

You’ll notice that the code is identical until we get to the Select-Object statement. Here we use the AttributeValue property to identify each Member. Here’s some sample output:

Image of command output

Like tears in rain…time to remediate

What about checking for LEGACYs in a single group?

#Check a single group for LEGACY members

$DN = "cn=Users,cn=Builtin,dc=Contoso,dc=Com"

$NonLVRMembers =  Get-ADReplicationAttributeMetadata          -Object $DN

-Server rootdc01.contoso.com

-Properties Member

-ShowAllLinkedValues | Where-Object {$_.Version -eq 0}

The objects in $NonLVRMembers are the equivalent of a LEGACY value in repadmin. Here’s an example object:

Image of command output

What does a PRESENT value object look like? Here you go:

Image of command output

Notice the difference in the attributes reported between these two member values—PRESENT has replication metadata.

As mentioned earlier, converting a LEGACY member to PRESENT is a matter of removing and re-adding the member to the group.

For our $NonLVRMembers example, here’s the preconversion metadata according to repadmin:

Image of command output

(A member deleted from the group is marked as ABSENT during the tombstone lifetime.)

Use PowerShell to retire those LEGACYs

#Remove the LEGACY members from a particular group

Remove-ADGroupMember -Identity $DN -Members ($NonLVRMembers).AttributeValue -Server rootdc01.contoso.com

Now, use Windows PowerShell to reinstate memberships:

#Add the old LEGACY members back into a particular group

Add-ADGroupMember -Identity $DN -Members ($NonLVRMembers).AttributeValue -Server rootdc01.contoso.com

Here’s a command to look at all the Member values associated with the group:

Get-ADReplicationAttributeMetadata -Object $DN -Server rootdc01.contoso.com -Properties Member -ShowAllLinkedValues

All returned objects should now have replication metadata. Here’s what our updated LEGACY member value now looks like:

Image of command output

And, here’s the example group, post-conversion, according to repadmin:

Image of command output

Retiring LEGACYs is almost as cool as watching C-beams glitter in the dark near the Tannhauser Gate!

Right. Where’s that Vangelis album…

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

2 comments

Discussion is closed. Login to edit/delete existing comments.

  • Phillip Boyd 0

    This is a great write up on the Legacy members and how to remediate using PowerShell

  • Jelle 0

    Great article, the only object that I could not “fix” is the Administrator account in de Administrators group. Since this these are built-in objects, I cannot remove and re-add the administrator account to the Administrators group.
    Is there another way this can be fixed?

Feedback usabilla icon