| Author | Messages | |
adwulf
Posts:112
 | | 04/27/2012 12:01 PM |
| Dear Fount of All AD Knowledge,
As I've mentioned in a recent thread, I have seen DCs in a customer's
environment being taken out by version storage depletion - and I found
that they had some groups with up to 8,000 members, which had been
created prior to raising the DFL/FFL to Windows 2003.
It appears that two groups in particular are the issue, with > 5,000
group members stored in the legacy format.
Now, I am aware that by removing the group members, and adding them
back in again, they will be stored using the new 'linked value' format
- which does not cause the version storage to be depleted. However -
surely, by removing the legacy membership (or even just a few such
members), I will cause the entire legacy group membership to be
replicated out - causing version storage depletion?
Ideally, I would just create new, replacement groups with the same
membership lists, but various application teams are reluctant to have
these groups deleted, fearing some as yet unknown issue when changing
which groups their applications use.
Is there a way of converting legacy group membership lists to the new
LVR format, which won't cause version store depletion?
Currently, I am looking at increasing the amount of version store
memory on each DC, and then clearing out these groups - however, I am
unable to test this approach, as the Alpha and Beta test forests do
not contain anywhere near the same volume of users in the legacy
membership format.
Has anyone used this approach before now? Did it work?
Or - if changing the group membership in any manner will cause it to
be replicated in full; if I were to remove 5,000 members from the
group (eg by dsa.msc) - would that replicate the group membership list
5,000 times (each iteration one member shorter than the last)? Or
would it replicate the list out once with the newer list of members,
5,000 objects shorter than the previous list?
Many thanks in advance for any advice/help/suggestions,
--
AdamT
List info: http://www.activedir.org/List.aspx
| | | |
| ZJORZ
Posts:450
| | 04/27/2012 12:24 PM |
| WHEN does the "version storage depletion" occur? During what action?
When a group contains legacy memberships added before ffl w2k3, but now the ffl is w2k3 or higher, any member addition or removal with leverage lvr right away.
So in your case, when does this happen?
Met vriendelijke groet / Kind regards,
Jorge de Almeida Pinto
Tel.: +31-(06)-26.26.62.80
(Sent from my Windows Phone)
________________________________
From: Adam Thompson
Sent: 2012-04-27 13:02
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: [ActiveDir] LVR/Legacy Group Membership
Dear Fount of All AD Knowledge,
As I've mentioned in a recent thread, I have seen DCs in a customer's
environment being taken out by version storage depletion - and I found
that they had some groups with up to 8,000 members, which had been
created prior to raising the DFL/FFL to Windows 2003.
It appears that two groups in particular are the issue, with > 5,000
group members stored in the legacy format.
Now, I am aware that by removing the group members, and adding them
back in again, they will be stored using the new 'linked value' format
- which does not cause the version storage to be depleted. However -
surely, by removing the legacy membership (or even just a few such
members), I will cause the entire legacy group membership to be
replicated out - causing version storage depletion?
Ideally, I would just create new, replacement groups with the same
membership lists, but various application teams are reluctant to have
these groups deleted, fearing some as yet unknown issue when changing
which groups their applications use.
Is there a way of converting legacy group membership lists to the new
LVR format, which won't cause version store depletion?
Currently, I am looking at increasing the amount of version store
memory on each DC, and then clearing out these groups - however, I am
unable to test this approach, as the Alpha and Beta test forests do
not contain anywhere near the same volume of users in the legacy
membership format.
Has anyone used this approach before now? Did it work?
Or - if changing the group membership in any manner will cause it to
be replicated in full; if I were to remove 5,000 members from the
group (eg by dsa.msc) - would that replicate the group membership list
5,000 times (each iteration one member shorter than the last)? Or
would it replicate the list out once with the newer list of members,
5,000 objects shorter than the previous list?
Many thanks in advance for any advice/help/suggestions,
--
AdamT
List info: http://www.activedir.org/List.aspx
| | | |
| adwulf
Posts:112
| | 04/27/2012 1:49 PM |
| Hi Jorge,
Many thanks for your reply.
It appears to happen when a 'legacy' member is removed from one of these groups.
My understanding was that removing a member from the non-LVR
membership list would still cause the entire non-LVR list to be
replicated.
For example, a group has the following members:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - LVR
Alice - LVR
Removing Bob or Alice (or adding a new member) will mean LVR is used.
Removing 'Tom' will cause the entire legacy group membership to be replicated.
Or have I misunderstood this?
I've been going on this:
http://www.windowsitpro.com/article/domains2/q-how-are-active-directory-ad-security-group-memberships-replicated-between-different-domain-controller-dc-ad-instances-does-ad-handle-replications-differently-in-windows-server-2003-than-in-windows-2000-
Which says: "After you upgrade your AD forest to Windows 2003 and
switch its functionality level, legacy groups can still cause group
membership change losses. Also, those groups' memberships will still
be replicated using the legacy attribute-level replication mechanism."
But I'm not able to find something on
Technet/MSDN/support.microsoft.com which says the same sort of thing.
Thanks,
Adam.
On 27 April 2012 12:23, Jorge De Almeida Pinto
<jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> WHEN does the "version storage depletion" occur? During what action?
>
> When a group contains legacy memberships added before ffl w2k3, but now the
> ffl is w2k3 or higher, any member addition or removal with leverage lvr
> right away.
>
> So in your case, when does this happen?
>
> Met vriendelijke groet / Kind regards,
> Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
List info: http://www.activedir.org/List.aspx
| | | |
| kbatkbslpcom
Posts:216
| | 04/27/2012 2:25 PM |
| Please...when you find the answer to this, please post it.
I'm in a similar situation (only without the version store issues) - and do need to start 'converting' some of our larger groups (in multiple forests) to start using LVR.
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 8:47 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Hi Jorge,
Many thanks for your reply.
It appears to happen when a 'legacy' member is removed from one of these groups.
My understanding was that removing a member from the non-LVR
membership list would still cause the entire non-LVR list to be
replicated.
For example, a group has the following members:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - LVR
Alice - LVR
Removing Bob or Alice (or adding a new member) will mean LVR is used.
Removing 'Tom' will cause the entire legacy group membership to be replicated.
Or have I misunderstood this?
I've been going on this:
http://www.windowsitpro.com/article/domains2/q-how-are-active-directory-ad-security-group-memberships-replicated-between-different-domain-controller-dc-ad-instances-does-ad-handle-replications-differently-in-windows-server-2003-than-in-windows-2000-
Which says: "After you upgrade your AD forest to Windows 2003 and
switch its functionality level, legacy groups can still cause group
membership change losses. Also, those groups' memberships will still
be replicated using the legacy attribute-level replication mechanism."
But I'm not able to find something on
Technet/MSDN/support.microsoft.com which says the same sort of thing.
Thanks,
Adam.
On 27 April 2012 12:23, Jorge De Almeida Pinto
<jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> WHEN does the "version storage depletion" occur? During what action?
>
> When a group contains legacy memberships added before ffl w2k3, but now the
> ffl is w2k3 or higher, any member addition or removal with leverage lvr
> right away.
>
> So in your case, when does this happen?
>
> Met vriendelijke groet / Kind regards,
> Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| ZJORZ
Posts:450
| | 04/27/2012 2:52 PM |
| Do you guys have issues when promoting new dcs?
Met vriendelijke groet / Kind regards,
Jorge de Almeida Pinto
Tel.: +31-(06)-26.26.62.80
(Sent from my Windows Phone)
________________________________
From: Adam Thompson
Sent: 2012-04-27 14:48
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Hi Jorge,
Many thanks for your reply.
It appears to happen when a 'legacy' member is removed from one of these groups.
My understanding was that removing a member from the non-LVR
membership list would still cause the entire non-LVR list to be
replicated.
For example, a group has the following members:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - LVR
Alice - LVR
Removing Bob or Alice (or adding a new member) will mean LVR is used.
Removing 'Tom' will cause the entire legacy group membership to be replicated.
Or have I misunderstood this?
I've been going on this:
http://www.windowsitpro.com/article/domains2/q-how-are-active-directory-ad-security-group-memberships-replicated-between-different-domain-controller-dc-ad-instances-does-ad-handle-replications-differently-in-windows-server-2003-than-in-windows-2000-
Which says: "After you upgrade your AD forest to Windows 2003 and
switch its functionality level, legacy groups can still cause group
membership change losses. Also, those groups' memberships will still
be replicated using the legacy attribute-level replication mechanism."
But I'm not able to find something on
Technet/MSDN/support.microsoft.com which says the same sort of thing.
Thanks,
Adam.
On 27 April 2012 12:23, Jorge De Almeida Pinto
<jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> WHEN does the "version storage depletion" occur? During what action?
>
> When a group contains legacy memberships added before ffl w2k3, but now the
> ffl is w2k3 or higher, any member addition or removal with leverage lvr
> right away.
>
> So in your case, when does this happen?
>
> Met vriendelijke groet / Kind regards,
> Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
List info: http://www.activedir.org/List.aspx
| | | |
| esf
Posts:19
| | 04/27/2012 2:56 PM |
| I'm fairly skeptical of the claim but we would need to debug to know for sure.
Adding or removing a single link value will decorate that value with LVR metadata. It will replicate on its own. Other members not touched by the operation are not decorated, but they are also not replicated (only during other operations are they replicated, like dcpromo or auth restore).
I am also somewhat skeptical that an 8K member group, even when replicated w/o LVR metadata, will cause an OOVS situation on a DC in calendar year 2012, given advances that have happened since that guidance was first published. But anything is possible, that's just my gut talking, not data.
The most scientific way to get to the bottom of an OOVS condition is to attach a debugger to the DC and set a breakpoint on the OOVS condition. You can then dump the appropriate data out of the state of the DC and know with certainty what is causing the condition.
That said, this will cause a service outage for the DC whenthe OOVS condition hits, so you would need to be ok with it. The outage would last until you dump the state and restore service (you would probably want to cycle the DC to detacth the debugger while you are at it).
If you're interested in that let me know and I can get you the breakpoint. It would require knowledge of debugging Windows (kd/ntsd/windbg).
Thx,
~Eric
(former MSFT dude)
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Brown, Ken F.
Sent: Friday, April 27, 2012 6:23 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
Please...when you find the answer to this, please post it.
I'm in a similar situation (only without the version store issues) - and do need to start 'converting' some of our larger groups (in multiple forests) to start using LVR.
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 8:47 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Hi Jorge,
Many thanks for your reply.
It appears to happen when a 'legacy' member is removed from one of these groups.
My understanding was that removing a member from the non-LVR membership list would still cause the entire non-LVR list to be replicated.
For example, a group has the following members:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - LVR
Alice - LVR
Removing Bob or Alice (or adding a new member) will mean LVR is used.
Removing 'Tom' will cause the entire legacy group membership to be replicated.
Or have I misunderstood this?
I've been going on this:
http://www.windowsitpro.com/article/domains2/q-how-are-active-directory-ad-security-group-memberships-replicated-between-different-domain-controller-dc-ad-instances-does-ad-handle-replications-differently-in-windows-server-2003-than-in-windows-2000-
Which says: "After you upgrade your AD forest to Windows 2003 and switch its functionality level, legacy groups can still cause group membership change losses. Also, those groups' memberships will still be replicated using the legacy attribute-level replication mechanism."
But I'm not able to find something on
Technet/MSDN/support.microsoft.com which says the same sort of thing.
Thanks,
Adam.
On 27 April 2012 12:23, Jorge De Almeida Pinto <jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> WHEN does the "version storage depletion" occur? During what action?
>
> When a group contains legacy memberships added before ffl w2k3, but
> now the ffl is w2k3 or higher, any member addition or removal with
> leverage lvr right away.
>
> So in your case, when does this happen?
>
> Met vriendelijke groet / Kind regards, Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| ZJORZ
Posts:450
| | 04/27/2012 3:07 PM |
| It is really weird... I have a group with 20000 legacy members.....works like a charm
Met vriendelijke groet / Kind regards,
Jorge de Almeida Pinto
Tel.: +31-(06)-26.26.62.80
(Sent from my Windows Phone)
________________________________
From: Brown, Ken F.
Sent: 2012-04-27 15:25
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
Please...when you find the answer to this, please post it.
I'm in a similar situation (only without the version store issues) - and do need to start 'converting' some of our larger groups (in multiple forests) to start using LVR.
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 8:47 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Hi Jorge,
Many thanks for your reply.
It appears to happen when a 'legacy' member is removed from one of these groups.
My understanding was that removing a member from the non-LVR
membership list would still cause the entire non-LVR list to be
replicated.
For example, a group has the following members:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - LVR
Alice - LVR
Removing Bob or Alice (or adding a new member) will mean LVR is used.
Removing 'Tom' will cause the entire legacy group membership to be replicated.
Or have I misunderstood this?
I've been going on this:
http://www.windowsitpro.com/article/domains2/q-how-are-active-directory-ad-security-group-memberships-replicated-between-different-domain-controller-dc-ad-instances-does-ad-handle-replications-differently-in-windows-server-2003-than-in-windows-2000-
Which says: "After you upgrade your AD forest to Windows 2003 and
switch its functionality level, legacy groups can still cause group
membership change losses. Also, those groups' memberships will still
be replicated using the legacy attribute-level replication mechanism."
But I'm not able to find something on
Technet/MSDN/support.microsoft.com which says the same sort of thing.
Thanks,
Adam.
On 27 April 2012 12:23, Jorge De Almeida Pinto
<jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> WHEN does the "version storage depletion" occur? During what action?
>
> When a group contains legacy memberships added before ffl w2k3, but now the
> ffl is w2k3 or higher, any member addition or removal with leverage lvr
> right away.
>
> So in your case, when does this happen?
>
> Met vriendelijke groet / Kind regards,
> Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| adwulf
Posts:112
| | 04/27/2012 3:09 PM |
| No issues with DCpromo (that I'm aware of). There have been some DC
promotions and removals recently -but the version storage issues have
happened weeks before and after these events.
OS and service pack are mostly Win 2003 x64 Standard Edition SP2.
There's still some Win 2003 x86 SP2 DCs in other sites, though.
Thanks,
Adam.
On 27 April 2012 14:56, Jorge De Almeida Pinto
<jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> Something else.....
>
> What's the os and sp?
>
>
> Met vriendelijke groet / Kind regards,
> Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
List info: http://www.activedir.org/List.aspx
| | | |
| adwulf
Posts:112
| | 04/27/2012 3:24 PM |
| Knowing where to set the breakpoint would definitely help. I have
some experience of WinDBG/KD - but mostly for driver/kernel stuff.
Most of my 'usermode' debugging has been done for stuff that I have
written myself, or against sample applications written specifically
for the purpose of teaching debugging. Is there anything special
about debugging lsass I should know?
Would I be able to attach the debugger in an RDP session? Or would
lsass having been broken into by the debugger stop me from connecting?
All DCs are physical, and exist in several sites around the world.
Some sites don't have iLO, so I won't be able to do any serial
debugging on them.
Perhaps I could use Sysinternals procdump with "-b <breakpoint>" to
get a dump. That would also help prevent cases in which the issue
occurs and somebody on shift just power cycles the DC.
As for the 8k member group not causing an issue (and Jorge has
mentioned groups with 20k legacy members) - I think that version store
space is limited to 100 MB by default (unless you have less than 400
MB RAM, in which case it'll be 25% of that). So it shouldn't matter
whether you have an x86 DC with 512 MB RAM, or an x64 DC with 64 GB.
The version store space will be 100 MB.
Thanks for the response,
Adam.
On 27 April 2012 14:53, Eric Fleischman <eric@xxxxxxxxxxxxxxxx> wrote:
> I'm fairly skeptical of the claim but we would need to debug to know for sure.
>
> Adding or removing a single link value will decorate that value with LVR metadata. It will replicate on its own. Other members not touched by the operation are not decorated, but they are also not replicated (only during other operations are they replicated, like dcpromo or auth restore).
>
> I am also somewhat skeptical that an 8K member group, even when replicated w/o LVR metadata, will cause an OOVS situation on a DC in calendar year 2012, given advances that have happened since that guidance was first published. But anything is possible, that's just my gut talking, not data.
>
> The most scientific way to get to the bottom of an OOVS condition is to attach a debugger to the DC and set a breakpoint on the OOVS condition. You can then dump the appropriate data out of the state of the DC and know with certainty what is causing the condition.
> That said, this will cause a service outage for the DC whenthe OOVS condition hits, so you would need to be ok with it. The outage would last until you dump the state and restore service (you would probably want to cycle the DC to detacth the debugger while you are at it).
>
> If you're interested in that let me know and I can get you the breakpoint. It would require knowledge of debugging Windows (kd/ntsd/windbg).
>
> Thx,
> ~Eric
> (former MSFT dude)
>
List info: http://www.activedir.org/List.aspx
| | | |
| adwulf
Posts:112
| | 04/27/2012 3:30 PM |
| Thanks, Jorge.
So going back to my theoretical group membership:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
After removing 'Tom', the list would look like this:
Tom - ABSENT
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
?
If so, when the change is implemented on the DC - would it then have
to load the entire list of legacy members into memory, remove 'Tom',
add him back in (LVR) as 'ABSENT' and then write the LVR and legacy
group membership to the DIT?
Thanks again,
Adam.
On 27 April 2012 14:52, Jorge De Almeida Pinto
<jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> For any linked attribute, and especially multi-valued linked attributes, the
> changes (both adds and removes) to the attribute in terms of storage and
> replication will leverage lvr as soon as that change occurs after ffl is
> w2k3 or higher. This also applies to values established before ffl is w2k3.
> With legacy values you will see that the usn and version of a linked
> attribute does not change anymore, but rather the usn and version of the
> value changes.
> You can see the latter with:
> Repadmin /showobjmeta dc "dn if group"
>
> Legacy values will show as legacy.
>
> Added New values will show as present.
>
> Remove new values will show as absent for the length of the tombstone
> lifetime
>
>
> Met vriendelijke groet / Kind regards,
> Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
> From: Adam Thompson
> Sent: 2012-04-27 14:48
> To: activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] LVR/Legacy Group Membership
>
> Hi Jorge,
>
> Many thanks for your reply.
>
> It appears to happen when a 'legacy' member is removed from one of these
> groups.
>
> My understanding was that removing a member from the non-LVR
> membership list would still cause the entire non-LVR list to be
> replicated.
>
> For example, a group has the following members:
>
> Tom - LEGACY
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - LVR
> Alice - LVR
>
> Removing Bob or Alice (or adding a new member) will mean LVR is used.
>
> Removing 'Tom' will cause the entire legacy group membership to be
> replicated.
>
>
> Or have I misunderstood this?
>
> I've been going on this:
>
> http://www.windowsitpro.com/article/domains2/q-how-are-active-directory-ad-security-group-memberships-replicated-between-different-domain-controller-dc-ad-instances-does-ad-handle-replications-differently-in-windows-server-2003-than-in-windows-2000-
>
> Which says: "After you upgrade your AD forest to Windows 2003 and
> switch its functionality level, legacy groups can still cause group
> membership change losses. Also, those groups' memberships will still
> be replicated using the legacy attribute-level replication mechanism."
>
> But I'm not able to find something on
> Technet/MSDN/support.microsoft.com which says the same sort of thing.
>
>
> Thanks,
>
> Adam.
--
AdamT
Гладна мечка хоро не играе.
A hungry bear doesn't dance.
List info: http://www.activedir.org/List.aspx
| | | |
| DonH
Posts:75
| | 04/27/2012 4:21 PM |
| Not quite. Think of the version store not as holding VALUES, but rather as
holding CHANGES. If you remove Tom then your final list would look like:
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
With Tom simply no longer being there. During the update, however, the
version store would hold the following:
REMOVE Tom
REMOVE Dick
REMOVE Harry
REMOVE Curly
REMOVE Larry
REMOVE Moe
ADD Dick
ADD Harry
ADD Curly
ADD Larry
ADD Moe
To make it worse, the version store is shared among all database updates
currently in flight. An operation may fail or succeed depending on what
else is going on in AD at the same time.
If it were me (and it was in the distant past), I would delete all the
legacy members in a single operation, LET THAT CHANGE PROPAGATE TO ALL
REPLICA DCs, and then start re-adding the members. That way you've reduced
the size of the biggest operation from "delete 8000 and add 7999" to "delete
8000".
Don Hacherl
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx
[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 7:28 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Thanks, Jorge.
So going back to my theoretical group membership:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
After removing 'Tom', the list would look like this:
Tom - ABSENT
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
?
If so, when the change is implemented on the DC - would it then have to load
the entire list of legacy members into memory, remove 'Tom', add him back in
(LVR) as 'ABSENT' and then write the LVR and legacy group membership to the
DIT?
Thanks again,
Adam.
On 27 April 2012 14:52, Jorge De Almeida Pinto
<jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> For any linked attribute, and especially multi-valued linked
> attributes, the changes (both adds and removes) to the attribute in
> terms of storage and replication will leverage lvr as soon as that
> change occurs after ffl is
> w2k3 or higher. This also applies to values established before ffl is
w2k3.
> With legacy values you will see that the usn and version of a linked
> attribute does not change anymore, but rather the usn and version of
> the value changes.
> You can see the latter with:
> Repadmin /showobjmeta dc "dn if group"
>
> Legacy values will show as legacy.
>
> Added New values will show as present.
>
> Remove new values will show as absent for the length of the tombstone
> lifetime
>
>
> Met vriendelijke groet / Kind regards, Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
> From: Adam Thompson
> Sent: 2012-04-27 14:48
> To: activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] LVR/Legacy Group Membership
>
> Hi Jorge,
>
> Many thanks for your reply.
>
> It appears to happen when a 'legacy' member is removed from one of
> these groups.
>
> My understanding was that removing a member from the non-LVR
> membership list would still cause the entire non-LVR list to be
> replicated.
>
> For example, a group has the following members:
>
> Tom - LEGACY
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - LVR
> Alice - LVR
>
> Removing Bob or Alice (or adding a new member) will mean LVR is used.
>
> Removing 'Tom' will cause the entire legacy group membership to be
> replicated.
>
>
> Or have I misunderstood this?
>
> I've been going on this:
>
> http://www.windowsitpro.com/article/domains2/q-how-are-active-director
> y-ad-security-group-memberships-replicated-between-different-domain-co
> ntroller-dc-ad-instances-does-ad-handle-replications-differently-in-wi
> ndows-server-2003-than-in-windows-2000-
>
> Which says: "After you upgrade your AD forest to Windows 2003 and
> switch its functionality level, legacy groups can still cause group
> membership change losses. Also, those groups' memberships will still
> be replicated using the legacy attribute-level replication mechanism."
>
> But I'm not able to find something on
> Technet/MSDN/support.microsoft.com which says the same sort of thing.
>
>
> Thanks,
>
> Adam.
--
AdamT
Гладна мечка хоро не играе.
A hungry bear doesn't dance.
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| esf
Posts:19
| | 04/27/2012 5:47 PM |
| The idea of the bp would be to set it on the ESE method where we have recognized that there is an OOVS condition. Then you can take a dump (.dump /ma style). From there you can cycle the machine (to get the kd off of the box) and let it enter service, analyzing the dump offline.
To do the analysis from there you would use the ESE debugger extension which helps translate random bits of memory in to rational datastructures.
To Don's point in the parallel fork of the thread, to really have a big picture view of everything using version store you really need to analyze everything. Setting the BP will capture the machine "in the worst state" and you can easily see what the offending thread is that pushed you over the edge. But the guy that pushed you over the edge might not be the real culprit. If someone uses 99% of capacity, then someone else comes along and uses 2%, is it the 2% guys fault for pushing you over or the 99% guys fault for taking you so close?
To be honest, I would suggest getting PSS help to do this, if this is the path you want to go. Having someone walk you through it that has done it before is probably beneficial. 
~E
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 7:32 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Something I should have asked below: how, with an lsass process dump, would you identify which region of memory is the version store?
Is there an easy trick for dumping it out, or something to look for on the call stack, or is it a matter of running s -a|u 'somestring'
<process virtual address range>?
On 27 April 2012 15:21, Adam Thompson <adwulf@xxxxxxxxxxxxxxxx> wrote:
> Knowing where to set the breakpoint would definitely help. I have
> some experience of WinDBG/KD - but mostly for driver/kernel stuff.
> Most of my 'usermode' debugging has been done for stuff that I have
> written myself, or against sample applications written specifically
> for the purpose of teaching debugging. Is there anything special
> about debugging lsass I should know?
>
> Would I be able to attach the debugger in an RDP session? Or would
> lsass having been broken into by the debugger stop me from connecting?
> All DCs are physical, and exist in several sites around the world.
> Some sites don't have iLO, so I won't be able to do any serial
> debugging on them.
>
> Perhaps I could use Sysinternals procdump with "-b <breakpoint>" to
> get a dump. That would also help prevent cases in which the issue
> occurs and somebody on shift just power cycles the DC.
>
> As for the 8k member group not causing an issue (and Jorge has
> mentioned groups with 20k legacy members) - I think that version store
> space is limited to 100 MB by default (unless you have less than 400
> MB RAM, in which case it'll be 25% of that). So it shouldn't matter
> whether you have an x86 DC with 512 MB RAM, or an x64 DC with 64 GB.
> The version store space will be 100 MB.
>
> Thanks for the response,
>
>
> Adam.
>
> On 27 April 2012 14:53, Eric Fleischman <eric@xxxxxxxxxxxxxxxx> wrote:
>> I'm fairly skeptical of the claim but we would need to debug to know for sure.
>>
>> Adding or removing a single link value will decorate that value with LVR metadata. It will replicate on its own. Other members not touched by the operation are not decorated, but they are also not replicated (only during other operations are they replicated, like dcpromo or auth restore).
>>
>> I am also somewhat skeptical that an 8K member group, even when replicated w/o LVR metadata, will cause an OOVS situation on a DC in calendar year 2012, given advances that have happened since that guidance was first published. But anything is possible, that's just my gut talking, not data.
>>
>> The most scientific way to get to the bottom of an OOVS condition is to attach a debugger to the DC and set a breakpoint on the OOVS condition. You can then dump the appropriate data out of the state of the DC and know with certainty what is causing the condition.
>> That said, this will cause a service outage for the DC whenthe OOVS condition hits, so you would need to be ok with it. The outage would last until you dump the state and restore service (you would probably want to cycle the DC to detacth the debugger while you are at it).
>>
>> If you're interested in that let me know and I can get you the breakpoint. It would require knowledge of debugging Windows (kd/ntsd/windbg).
>>
>> Thx,
>> ~Eric
>> (former MSFT dude)
>>
--
AdamT
Гладна мечка хоро не играе.
A hungry bear doesn't dance.
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| bdesmond
Posts:1042
| | 04/27/2012 5:53 PM |
| Is the ESE extension even public and/or does it require private symbols? Either of those is going to be important.
Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx
w - 312.625.1438 | c - 312.731.3132
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, April 27, 2012 11:46 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
The idea of the bp would be to set it on the ESE method where we have recognized that there is an OOVS condition. Then you can take a dump (.dump /ma style). From there you can cycle the machine (to get the kd off of the box) and let it enter service, analyzing the dump offline.
To do the analysis from there you would use the ESE debugger extension which helps translate random bits of memory in to rational datastructures.
To Don's point in the parallel fork of the thread, to really have a big picture view of everything using version store you really need to analyze everything. Setting the BP will capture the machine "in the worst state" and you can easily see what the offending thread is that pushed you over the edge. But the guy that pushed you over the edge might not be the real culprit. If someone uses 99% of capacity, then someone else comes along and uses 2%, is it the 2% guys fault for pushing you over or the 99% guys fault for taking you so close?
To be honest, I would suggest getting PSS help to do this, if this is the path you want to go. Having someone walk you through it that has done it before is probably beneficial.
~E
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 7:32 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Something I should have asked below: how, with an lsass process dump, would you identify which region of memory is the version store?
Is there an easy trick for dumping it out, or something to look for on the call stack, or is it a matter of running s -a|u 'somestring'
<process virtual address range>?
On 27 April 2012 15:21, Adam Thompson <adwulf@xxxxxxxxxxxxxxxx> wrote:
> Knowing where to set the breakpoint would definitely help. I have
> some experience of WinDBG/KD - but mostly for driver/kernel stuff.
> Most of my 'usermode' debugging has been done for stuff that I have
> written myself, or against sample applications written specifically
> for the purpose of teaching debugging. Is there anything special
> about debugging lsass I should know?
>
> Would I be able to attach the debugger in an RDP session? Or would
> lsass having been broken into by the debugger stop me from connecting?
> All DCs are physical, and exist in several sites around the world.
> Some sites don't have iLO, so I won't be able to do any serial
> debugging on them.
>
> Perhaps I could use Sysinternals procdump with "-b <breakpoint>" to
> get a dump. That would also help prevent cases in which the issue
> occurs and somebody on shift just power cycles the DC.
>
> As for the 8k member group not causing an issue (and Jorge has
> mentioned groups with 20k legacy members) - I think that version store
> space is limited to 100 MB by default (unless you have less than 400
> MB RAM, in which case it'll be 25% of that). So it shouldn't matter
> whether you have an x86 DC with 512 MB RAM, or an x64 DC with 64 GB.
> The version store space will be 100 MB.
>
> Thanks for the response,
>
>
> Adam.
>
> On 27 April 2012 14:53, Eric Fleischman <eric@xxxxxxxxxxxxxxxx> wrote:
>> I'm fairly skeptical of the claim but we would need to debug to know for sure.
>>
>> Adding or removing a single link value will decorate that value with LVR metadata. It will replicate on its own. Other members not touched by the operation are not decorated, but they are also not replicated (only during other operations are they replicated, like dcpromo or auth restore).
>>
>> I am also somewhat skeptical that an 8K member group, even when replicated w/o LVR metadata, will cause an OOVS situation on a DC in calendar year 2012, given advances that have happened since that guidance was first published. But anything is possible, that's just my gut talking, not data.
>>
>> The most scientific way to get to the bottom of an OOVS condition is to attach a debugger to the DC and set a breakpoint on the OOVS condition. You can then dump the appropriate data out of the state of the DC and know with certainty what is causing the condition.
>> That said, this will cause a service outage for the DC whenthe OOVS condition hits, so you would need to be ok with it. The outage would last until you dump the state and restore service (you would probably want to cycle the DC to detacth the debugger while you are at it).
>>
>> If you're interested in that let me know and I can get you the breakpoint. It would require knowledge of debugging Windows (kd/ntsd/windbg).
>>
>> Thx,
>> ~Eric
>> (former MSFT dude)
>>
--
AdamT
Гладна мечка хоро не играе.
A hungry bear doesn't dance.
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| esf
Posts:19
| | 04/27/2012 6:25 PM |
| The extension itself is built in to the ESE DLL (esent.dll in this case).
I don't believe it has a dependency on private symbols...at least I don't remember such a dependency.
~E
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Brian Desmond
Sent: Friday, April 27, 2012 9:52 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
Is the ESE extension even public and/or does it require private symbols? Either of those is going to be important.
Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx
w - 312.625.1438 | c - 312.731.3132
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, April 27, 2012 11:46 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
The idea of the bp would be to set it on the ESE method where we have recognized that there is an OOVS condition. Then you can take a dump (.dump /ma style). From there you can cycle the machine (to get the kd off of the box) and let it enter service, analyzing the dump offline.
To do the analysis from there you would use the ESE debugger extension which helps translate random bits of memory in to rational datastructures.
To Don's point in the parallel fork of the thread, to really have a big picture view of everything using version store you really need to analyze everything. Setting the BP will capture the machine "in the worst state" and you can easily see what the offending thread is that pushed you over the edge. But the guy that pushed you over the edge might not be the real culprit. If someone uses 99% of capacity, then someone else comes along and uses 2%, is it the 2% guys fault for pushing you over or the 99% guys fault for taking you so close?
To be honest, I would suggest getting PSS help to do this, if this is the path you want to go. Having someone walk you through it that has done it before is probably beneficial.
~E
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 7:32 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Something I should have asked below: how, with an lsass process dump, would you identify which region of memory is the version store?
Is there an easy trick for dumping it out, or something to look for on the call stack, or is it a matter of running s -a|u 'somestring'
<process virtual address range>?
On 27 April 2012 15:21, Adam Thompson <adwulf@xxxxxxxxxxxxxxxx> wrote:
> Knowing where to set the breakpoint would definitely help. I have
> some experience of WinDBG/KD - but mostly for driver/kernel stuff.
> Most of my 'usermode' debugging has been done for stuff that I have
> written myself, or against sample applications written specifically
> for the purpose of teaching debugging. Is there anything special
> about debugging lsass I should know?
>
> Would I be able to attach the debugger in an RDP session? Or would
> lsass having been broken into by the debugger stop me from connecting?
> All DCs are physical, and exist in several sites around the world.
> Some sites don't have iLO, so I won't be able to do any serial
> debugging on them.
>
> Perhaps I could use Sysinternals procdump with "-b <breakpoint>" to
> get a dump. That would also help prevent cases in which the issue
> occurs and somebody on shift just power cycles the DC.
>
> As for the 8k member group not causing an issue (and Jorge has
> mentioned groups with 20k legacy members) - I think that version store
> space is limited to 100 MB by default (unless you have less than 400
> MB RAM, in which case it'll be 25% of that). So it shouldn't matter
> whether you have an x86 DC with 512 MB RAM, or an x64 DC with 64 GB.
> The version store space will be 100 MB.
>
> Thanks for the response,
>
>
> Adam.
>
> On 27 April 2012 14:53, Eric Fleischman <eric@xxxxxxxxxxxxxxxx> wrote:
>> I'm fairly skeptical of the claim but we would need to debug to know for sure.
>>
>> Adding or removing a single link value will decorate that value with LVR metadata. It will replicate on its own. Other members not touched by the operation are not decorated, but they are also not replicated (only during other operations are they replicated, like dcpromo or auth restore).
>>
>> I am also somewhat skeptical that an 8K member group, even when replicated w/o LVR metadata, will cause an OOVS situation on a DC in calendar year 2012, given advances that have happened since that guidance was first published. But anything is possible, that's just my gut talking, not data.
>>
>> The most scientific way to get to the bottom of an OOVS condition is to attach a debugger to the DC and set a breakpoint on the OOVS condition. You can then dump the appropriate data out of the state of the DC and know with certainty what is causing the condition.
>> That said, this will cause a service outage for the DC whenthe OOVS condition hits, so you would need to be ok with it. The outage would last until you dump the state and restore service (you would probably want to cycle the DC to detacth the debugger while you are at it).
>>
>> If you're interested in that let me know and I can get you the breakpoint. It would require knowledge of debugging Windows (kd/ntsd/windbg).
>>
>> Thx,
>> ~Eric
>> (former MSFT dude)
>>
--
AdamT
Гладна мечка хоро не играе.
A hungry bear doesn't dance.
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| sl
Posts:114
| | 04/27/2012 11:35 PM |
| Same here, larger groups and many too. Sometimes saturated international
links on the periphery. The version store problem is an effect. The
underlying cause needs to be addressed - there will be more effects than
just that.
regards
Slav
On 28/04/2012 12:06 AM, Jorge De Almeida Pinto wrote:
> It is really weird... I have a group with 20000 legacy
> members.....works like a charm
>
> Met vriendelijke groet / Kind regards,
> Jorge de Almeida Pinto
>
| | | |
| ZJORZ
Posts:450
| | 04/28/2012 10:54 AM |
| Honestly... I'm missing something here:
* STARTING POINT:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
* TOM IS REMOVED AS MEMBER OF THE GROUP (this is what I see with repadmin)
Tom - ABSENT
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
Only the removal of Tom as a member is replicated to the other DCs (at least
that's what I thought)
I do not understand the following part.
The part that I do not understand is:
· "why are the other members removed and added because I just
removed TOM????"
· Am I correct that only the removal of Tom replicates, or is there
more to it?
##############
With Tom simply no longer being there. During the update, however, the
version store would hold the following:
REMOVE Tom
REMOVE Dick
REMOVE Harry
REMOVE Curly
REMOVE Larry
REMOVE Moe
ADD Dick
ADD Harry
ADD Curly
ADD Larry
ADD Moe
##############
Would you therefore recommend to ALWAYS convert the group memberships from
legacy-style to lvr-style?
· Remove all members
· Allow removal members to replicate
· Re-add members
My opinion is/was to not convert the group membership as in terms of
replication with LVR only the changes are replicated and in terms of
recovery with an auth restore you have the LDF files created by ntdsutil
that can be importaed in addition to only those values that have been auth
restored (in case of auth restoring a group) because those values are using
the lvr-style. (legacy values are not auth restored automatically when auth
restoring the actual members)
Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
Ing. Jorge de Almeida Pinto
Principal Consultant
MVP Identity & Access - Directory Services | MCP/MCSE/MCITP | MCT | vTSP
(
<https://mvp.support.microsoft.com/profile=F8C04F4A-BFF2-453E-9AED-7DFEDAB0B
E10> MVP Profile) ( <http://jorgequestforknowledge.wordpress.com/> Blog)
-------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: <http://jorgequestforknowledge.wordpress.com/disclaimer/>
http://jorgequestforknowledge.wordpress.com/disclaimer/
-------------------------------
Description: Description: Description: Description: Description: Think Green
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx
[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Don Hacherl
Sent: Friday, April 27, 2012 17:20
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
Not quite. Think of the version store not as holding VALUES, but rather as
holding CHANGES. If you remove Tom then your final list would look like:
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
With Tom simply no longer being there. During the update, however, the
version store would hold the following:
REMOVE Tom
REMOVE Dick
REMOVE Harry
REMOVE Curly
REMOVE Larry
REMOVE Moe
ADD Dick
ADD Harry
ADD Curly
ADD Larry
ADD Moe
To make it worse, the version store is shared among all database updates
currently in flight. An operation may fail or succeed depending on what
else is going on in AD at the same time.
If it were me (and it was in the distant past), I would delete all the
legacy members in a single operation, LET THAT CHANGE PROPAGATE TO ALL
REPLICA DCs, and then start re-adding the members. That way you've reduced
the size of the biggest operation from "delete 8000 and add 7999" to "delete
8000".
Don Hacherl
-----Original Message-----
From: <mailto:activedir-owner@xxxxxxxxxxxxxxxx>
activedir-owner@xxxxxxxxxxxxxxxx
<mailto:[mailto:activedir-owner@xxxxxxxxxxxxxxxx]>
[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 7:28 AM
To: <mailto:activedir@xxxxxxxxxxxxxxxx> activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Thanks, Jorge.
So going back to my theoretical group membership:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
After removing 'Tom', the list would look like this:
Tom - ABSENT
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
?
If so, when the change is implemented on the DC - would it then have to load
the entire list of legacy members into memory, remove 'Tom', add him back in
(LVR) as 'ABSENT' and then write the LVR and legacy group membership to the
DIT?
Thanks again,
Adam.
On 27 April 2012 14:52, Jorge De Almeida Pinto <
<mailto:jorgedealmeidapinto@xxxxxxxxxxxxxxxx> jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> For any linked attribute, and especially multi-valued linked
> attributes, the changes (both adds and removes) to the attribute in
> terms of storage and replication will leverage lvr as soon as that
> change occurs after ffl is
> w2k3 or higher. This also applies to values established before ffl is
w2k3.
> With legacy values you will see that the usn and version of a linked
> attribute does not change anymore, but rather the usn and version of
> the value changes.
> You can see the latter with:
> Repadmin /showobjmeta dc "dn if group"
>
> Legacy values will show as legacy.
>
> Added New values will show as present.
>
> Remove new values will show as absent for the length of the tombstone
> lifetime
>
>
> Met vriendelijke groet / Kind regards, Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
> From: Adam Thompson
> Sent: 2012-04-27 14:48
> To: <mailto:activedir@xxxxxxxxxxxxxxxx> activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] LVR/Legacy Group Membership
>
> Hi Jorge,
>
> Many thanks for your reply.
>
> It appears to happen when a 'legacy' member is removed from one of
> these groups.
>
> My understanding was that removing a member from the non-LVR
> membership list would still cause the entire non-LVR list to be
> replicated.
>
> For example, a group has the following members:
>
> Tom - LEGACY
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - LVR
> Alice - LVR
>
> Removing Bob or Alice (or adding a new member) will mean LVR is used.
>
> Removing 'Tom' will cause the entire legacy group membership to be
> replicated.
>
>
> Or have I misunderstood this?
>
> I've been going on this:
>
> <http://www.windowsitpro.com/article/domains2/q-how-are-active-director>
http://www.windowsitpro.com/article/domains2/q-how-are-active-director
> y-ad-security-group-memberships-replicated-between-different-domain-co
> ntroller-dc-ad-instances-does-ad-handle-replications-differently-in-wi
> ndows-server-2003-than-in-windows-2000-
>
> Which says: "After you upgrade your AD forest to Windows 2003 and
> switch its functionality level, legacy groups can still cause group
> membership change losses. Also, those groups' memberships will still
> be replicated using the legacy attribute-level replication mechanism."
>
> But I'm not able to find something on
> Technet/MSDN/support.microsoft.com which says the same sort of thing.
>
>
> Thanks,
>
> Adam.
--
AdamT
Гладна мечка хоро не играе.
A hungry bear doesn't dance.
List info: <http://www.activedir.org/List.aspx>
http://www.activedir.org/List.aspx
List info: <http://www.activedir.org/List.aspx>
http://www.activedir.org/List.aspx
| | | |
| adwulf
Posts:112
| | 04/30/2012 10:33 AM |
| Isn't the version store for staging changes in memory before
committing them to the DIT?
If so, then surely it must contain the 'old style' membership format
as it looks after the changes have been made.
Eg:
The change is to remove legacy member 'Harry' from the list of 5,000
legacy members.
The DC will then have to have the entire legacy membership loaded into
version storage memory, remove member 'Harry', then write back the
list with the remaining 4,999 members.
Perhaps 5,000 members isn't enough to consume the entire version store
by itself - but if Harry is a leaver, whose account is being disabled
and removed from five or six such large groups - along with maybe 10
other leavers being processed in that batch - and the version store is
shared between all 'in flight' changes - could that be what tips it
over the edge?
On 27 April 2012 16:19, Don Hacherl <don@xxxxxxxxxxxxxxxx> wrote:
> Not quite. Think of the version store not as holding VALUES, but rather as
> holding CHANGES. If you remove Tom then your final list would look like:
>
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - PRESENT
> Alice - PRESENT
>
> With Tom simply no longer being there. During the update, however, the
> version store would hold the following:
>
> REMOVE Tom
> REMOVE Dick
> REMOVE Harry
> REMOVE Curly
> REMOVE Larry
> REMOVE Moe
> ADD Dick
> ADD Harry
> ADD Curly
> ADD Larry
> ADD Moe
>
> To make it worse, the version store is shared among all database updates
> currently in flight. An operation may fail or succeed depending on what
> else is going on in AD at the same time.
>
> If it were me (and it was in the distant past), I would delete all the
> legacy members in a single operation, LET THAT CHANGE PROPAGATE TO ALL
> REPLICA DCs, and then start re-adding the members. That way you've reduced
> the size of the biggest operation from "delete 8000 and add 7999" to "delete
> 8000".
>
> Don Hacherl
>
> -----Original Message-----
> From: activedir-owner@xxxxxxxxxxxxxxxx
> [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
> Sent: Friday, April 27, 2012 7:28 AM
> To: activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] LVR/Legacy Group Membership
>
> Thanks, Jorge.
>
> So going back to my theoretical group membership:
>
> Tom - LEGACY
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - PRESENT
> Alice - PRESENT
>
> After removing 'Tom', the list would look like this:
>
> Tom - ABSENT
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - PRESENT
> Alice - PRESENT
>
> ?
>
> If so, when the change is implemented on the DC - would it then have to load
> the entire list of legacy members into memory, remove 'Tom', add him back in
> (LVR) as 'ABSENT' and then write the LVR and legacy group membership to the
> DIT?
>
> Thanks again,
>
>
> Adam.
>
--
AdamT
List info: http://www.activedir.org/List.aspx
| | | |
| DonH
Posts:75
| | 04/30/2012 7:05 PM |
| Yes, the before and after versions of the membership list are held in
memory. That's what I tried to show. If an object is being removed from
several groups, then that's actually several different groups being
modified, and each modification is done in a separate database transaction,
with version store being released after each one. If a user is being
deleted then the removal of his memberships is done in a different way that
does not involve fully rewriting the membership list on the groups, nor does
it update the group membership metadata. Therefore deleting a user who is a
member of large groups does not pose a problem.
Don
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx
[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Monday, April 30, 2012 2:31 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Isn't the version store for staging changes in memory before committing them
to the DIT?
If so, then surely it must contain the 'old style' membership format as it
looks after the changes have been made.
Eg:
The change is to remove legacy member 'Harry' from the list of 5,000 legacy
members.
The DC will then have to have the entire legacy membership loaded into
version storage memory, remove member 'Harry', then write back the list with
the remaining 4,999 members.
Perhaps 5,000 members isn't enough to consume the entire version store by
itself - but if Harry is a leaver, whose account is being disabled and
removed from five or six such large groups - along with maybe 10 other
leavers being processed in that batch - and the version store is shared
between all 'in flight' changes - could that be what tips it over the edge?
On 27 April 2012 16:19, Don Hacherl <don@xxxxxxxxxxxxxxxx> wrote:
> Not quite. Think of the version store not as holding VALUES, but
> rather as holding CHANGES. If you remove Tom then your final list would
look like:
>
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - PRESENT
> Alice - PRESENT
>
> With Tom simply no longer being there. During the update, however,
> the version store would hold the following:
>
> REMOVE Tom
> REMOVE Dick
> REMOVE Harry
> REMOVE Curly
> REMOVE Larry
> REMOVE Moe
> ADD Dick
> ADD Harry
> ADD Curly
> ADD Larry
> ADD Moe
>
> To make it worse, the version store is shared among all database
> updates currently in flight. An operation may fail or succeed
> depending on what else is going on in AD at the same time.
>
> If it were me (and it was in the distant past), I would delete all the
> legacy members in a single operation, LET THAT CHANGE PROPAGATE TO ALL
> REPLICA DCs, and then start re-adding the members. That way you've
> reduced the size of the biggest operation from "delete 8000 and add
> 7999" to "delete 8000".
>
> Don Hacherl
>
> -----Original Message-----
> From: activedir-owner@xxxxxxxxxxxxxxxx
> [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
> Sent: Friday, April 27, 2012 7:28 AM
> To: activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] LVR/Legacy Group Membership
>
> Thanks, Jorge.
>
> So going back to my theoretical group membership:
>
> Tom - LEGACY
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - PRESENT
> Alice - PRESENT
>
> After removing 'Tom', the list would look like this:
>
> Tom - ABSENT
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - PRESENT
> Alice - PRESENT
>
> ?
>
> If so, when the change is implemented on the DC - would it then have
> to load the entire list of legacy members into memory, remove 'Tom',
> add him back in
> (LVR) as 'ABSENT' and then write the LVR and legacy group membership
> to the DIT?
>
> Thanks again,
>
>
> Adam.
>
--
AdamT
List info: http://www.activedir.org/List.aspx
List info: http://www.activedir.org/List.aspx
| | | |
| DonH
Posts:75
| | 04/30/2012 7:22 PM |
| What you're describing is the new LVR method. The old legacy method is
different. In LVR (link VALUE replication) each value is replicated and
tracked separately. In the legacy method, still used for all non-link
attributes, the ATTRIBUTE is the unit of replication. Remember, what is
replicated in AD is not actions ("delete X"), but rather states ("here is
the current version of X"). In pre-LVR group replication what was sent over
the wire was the current state of the group membership (e.g., "Dick, Harry,
Curly, Larry, Moe"). To apply that update the current state of the
attribute (i.e., all its values) is removed and is replaced by the new state
that came over the wire. It's too complicated to go into here, but doing it
this way helps guarantee replication convergence, so we never tried to
optimize it away.
With LVR it's still states rather than actions that replicates, but it's the
state of individual attribute values rather than of entire attributes. It's
like tombstoned objects. If Alice is added to a group under LVR then what
replicates is a thing that says "Alice is a member of group G". When she is
removed from the group what replicates is a value that says "Alice used to
be a member of Group G but isn't any more" .
I would certainly recommend enabling LVR. I would not proactively try to
wipe out legacy memberships unless you're having version store problems. If
you're in that sad state then I'd recommend doing the conversion proactively
during periods of low activity.
Don
From: activedir-owner@xxxxxxxxxxxxxxxx
[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Jorge de Almeida
Pinto
Sent: Saturday, April 28, 2012 2:52 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
Honestly... I'm missing something here:
* STARTING POINT:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
* TOM IS REMOVED AS MEMBER OF THE GROUP (this is what I see with repadmin)
Tom - ABSENT
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
Only the removal of Tom as a member is replicated to the other DCs (at least
that's what I thought)
I do not understand the following part.
The part that I do not understand is:
· "why are the other members removed and added because I just
removed TOM????"
· Am I correct that only the removal of Tom replicates, or is there
more to it?
##############
With Tom simply no longer being there. During the update, however, the
version store would hold the following:
REMOVE Tom
REMOVE Dick
REMOVE Harry
REMOVE Curly
REMOVE Larry
REMOVE Moe
ADD Dick
ADD Harry
ADD Curly
ADD Larry
ADD Moe
##############
Would you therefore recommend to ALWAYS convert the group memberships from
legacy-style to lvr-style?
· Remove all members
· Allow removal members to replicate
· Re-add members
My opinion is/was to not convert the group membership as in terms of
replication with LVR only the changes are replicated and in terms of
recovery with an auth restore you have the LDF files created by ntdsutil
that can be importaed in addition to only those values that have been auth
restored (in case of auth restoring a group) because those values are using
the lvr-style. (legacy values are not auth restored automatically when auth
restoring the actual members)
Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
Ing. Jorge de Almeida Pinto
Principal Consultant
MVP Identity & Access - Directory Services | MCP/MCSE/MCITP | MCT | vTSP
(MVP Profile
<https://mvp.support.microsoft.com/profile=F8C04F4A-BFF2-453E-9AED-7DFEDAB0B
E10> ) (Blog <http://jorgequestforknowledge.wordpress.com/> )
-------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: <http://jorgequestforknowledge.wordpress.com/disclaimer/>
http://jorgequestforknowledge.wordpress.com/disclaimer/
-------------------------------
Description: Description: Description: Description: Description: Think Green
-----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx
[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Don Hacherl
Sent: Friday, April 27, 2012 17:20
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
Not quite. Think of the version store not as holding VALUES, but rather as
holding CHANGES. If you remove Tom then your final list would look like:
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
With Tom simply no longer being there. During the update, however, the
version store would hold the following:
REMOVE Tom
REMOVE Dick
REMOVE Harry
REMOVE Curly
REMOVE Larry
REMOVE Moe
ADD Dick
ADD Harry
ADD Curly
ADD Larry
ADD Moe
To make it worse, the version store is shared among all database updates
currently in flight. An operation may fail or succeed depending on what
else is going on in AD at the same time.
If it were me (and it was in the distant past), I would delete all the
legacy members in a single operation, LET THAT CHANGE PROPAGATE TO ALL
REPLICA DCs, and then start re-adding the members. That way you've reduced
the size of the biggest operation from "delete 8000 and add 7999" to "delete
8000".
Don Hacherl
-----Original Message-----
From: <mailto:activedir-owner@xxxxxxxxxxxxxxxx>
activedir-owner@xxxxxxxxxxxxxxxx
<mailto:[mailto:activedir-owner@xxxxxxxxxxxxxxxx]>
[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam Thompson
Sent: Friday, April 27, 2012 7:28 AM
To: <mailto:activedir@xxxxxxxxxxxxxxxx> activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] LVR/Legacy Group Membership
Thanks, Jorge.
So going back to my theoretical group membership:
Tom - LEGACY
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
After removing 'Tom', the list would look like this:
Tom - ABSENT
Dick - LEGACY
Harry - LEGACY
Curly - LEGACY
Larry - LEGACY
Moe - LEGACY
Bob - PRESENT
Alice - PRESENT
?
If so, when the change is implemented on the DC - would it then have to load
the entire list of legacy members into memory, remove 'Tom', add him back in
(LVR) as 'ABSENT' and then write the LVR and legacy group membership to the
DIT?
Thanks again,
Adam.
On 27 April 2012 14:52, Jorge De Almeida Pinto <
<mailto:jorgedealmeidapinto@xxxxxxxxxxxxxxxx> jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
> For any linked attribute, and especially multi-valued linked
> attributes, the changes (both adds and removes) to the attribute in
> terms of storage and replication will leverage lvr as soon as that
> change occurs after ffl is
> w2k3 or higher. This also applies to values established before ffl is
w2k3.
> With legacy values you will see that the usn and version of a linked
> attribute does not change anymore, but rather the usn and version of
> the value changes.
> You can see the latter with:
> Repadmin /showobjmeta dc "dn if group"
>
> Legacy values will show as legacy.
>
> Added New values will show as present.
>
> Remove new values will show as absent for the length of the tombstone
> lifetime
>
>
> Met vriendelijke groet / Kind regards, Jorge de Almeida Pinto
> Tel.: +31-(06)-26.26.62.80
> (Sent from my Windows Phone)
> ________________________________
> From: Adam Thompson
> Sent: 2012-04-27 14:48
> To: <mailto:activedir@xxxxxxxxxxxxxxxx> activedir@xxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] LVR/Legacy Group Membership
>
> Hi Jorge,
>
> Many thanks for your reply.
>
> It appears to happen when a 'legacy' member is removed from one of
> these groups.
>
> My understanding was that removing a member from the non-LVR
> membership list would still cause the entire non-LVR list to be
> replicated.
>
> For example, a group has the following members:
>
> Tom - LEGACY
> Dick - LEGACY
> Harry - LEGACY
> Curly - LEGACY
> Larry - LEGACY
> Moe - LEGACY
> Bob - LVR
> Alice - LVR
>
> Removing Bob or Alice (or adding a new member) will mean LVR is used.
>
> Removing 'Tom' will cause the entire legacy group membership to be
> replicated.
>
>
> Or have I misunderstood this?
>
> I've been going on this:
>
> <http://www.windowsitpro.com/article/domains2/q-how-are-active-director>
http://www.windowsitpro.com/article/domains2/q-how-are-active-director
> y-ad-security-group-memberships-replicated-between-different-domain-co
> ntroller-dc-ad-instances-does-ad-handle-replications-differently-in-wi
> ndows-server-2003-than-in-windows-2000-
>
> Which says: "After you upgrade your AD forest to Windows 2003 and
> switch its functionality level, legacy groups can still cause group
> membership change losses. Also, those groups' memberships will still
> be replicated using the legacy attribute-level replication mechanism."
>
> But I'm not able to find something on
> Technet/MSDN/support.microsoft.com which says the same sort of thing.
>
>
> Thanks,
>
> Adam.
--
AdamT
Гладна мечка хоро не играе.
A hungry bear doesn't dance.
List info: <http://www.activedir.org/List.aspx>
http://www.activedir.org/List.aspx
List info: <http://www.activedir.org/List.aspx>
http://www.activedir.org/List.aspx
| | | |
| ZJORZ
Posts:450
| | 04/30/2012 11:18 PM |
|
Hi Don, OK, we are on the same page. What you are saying in your last mail I already knew and understand. the following is PRE-LVR. I thought you meant to say that it is WITH LVR...and that's the part that I was missing With Tom simply no longer being there. During the update, however, the version store would hold the following: REMOVE TomREMOVE DickREMOVE HarryREMOVE CurlyREMOVE LarryREMOVE MoeADD DickADD HarryADD CurlyADD LarryADD Moe
Met vriendelijke groeten / Kind regards,
Jorge de Almeida Pinto
From: don@xxxxxxxxxxxxxxxx
To: activedir@xxxxxxxxxxxxxxxx
Date: Mon, 30 Apr 2012 11:19:24 -0700
Subject: RE: [ActiveDir] LVR/Legacy Group Membership
What you’re describing is the new LVR method. The old legacy method is different. In LVR (link VALUE replication) each value is replicated and tracked separately. In the legacy method, still used for all non-link attributes, the ATTRIBUTE is the unit of replication. Remember, what is replicated in AD is not actions (“delete X”), but rather states (“here is the current version of X”). In pre-LVR group replication what was sent over the wire was the current state of the group membership (e.g., “Dick, Harry, Curly, Larry, Moe”). To apply that update the current state of the attribute (i.e., all its values) is removed and is replaced by the new state that came over the wire. It’s too complicated to go into here, but doing it this way helps guarantee replication convergence, so we never tried to optimize it away. With LVR it’s still states rather than actions that replicates, but it’s the state of individual attribute values rather than of entire attributes. It’s like tombstoned objects. If Alice is added to a group under LVR then what replicates is a thing that says “Alice is a member of group G”. When she is removed from the group what replicates is a value that says “Alice used to be a member of Group G but isn’t any more” . I would certainly recommend enabling LVR. I would not proactively try to wipe out legacy memberships unless you’re having version store problems. If you’re in that sad state then I’d recommend doing the conversion proactively during periods of low activity. Don From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Jorge de Almeida Pinto
Sent: Saturday, April 28, 2012 2:52 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership Honestly... I'm missing something here… * STARTING POINT:Tom - LEGACYDick - LEGACYHarry - LEGACYCurly - LEGACYLarry - LEGACYMoe - LEGACYBob - PRESENTAlice - PRESENT * TOM IS REMOVED AS MEMBER OF THE GROUP (this is what I see with repadmin)Tom - ABSENTDick - LEGACYHarry - LEGACYCurly - LEGACYLarry - LEGACYMoe - LEGACYBob - PRESENTAlice - PRESENT Only the removal of Tom as a member is replicated to the other DCs (at least that’s what I thought) I do not understand the following part.The part that I do not understand is:· “why are the other members removed and added because I just removed TOM????”· Am I correct that only the removal of Tom replicates, or is there more to it?##############With Tom simply no longer being there. During the update, however, the version store would hold the following: REMOVE TomREMOVE DickREMOVE HarryREMOVE CurlyREMOVE LarryREMOVE MoeADD DickADD HarryADD CurlyADD LarryADD Moe############## Would you therefore recommend to ALWAYS convert the group memberships from legacy-style to lvr-style?· Remove all members· Allow removal members to replicate· Re-add members My opinion is/was to not convert the group membership as in terms of replication with LVR only the changes are replicated and in terms of recovery with an auth restore you have the LDF files created by ntdsutil that can be importaed in addition to only those values that have been auth restored (in case of auth restoring a group) because those values are using the lvr-style. (legacy values are not auth restored automatically when auth restoring the actual members) Cheers, (HOPEFULLY THIS INFORMATION HELPS YOU!) Ing. Jorge de Almeida PintoPrincipal ConsultantMVP Identity & Access - Directory Services | MCP/MCSE/MCITP | MCT | vTSP(MVP Profile) (Blog) ———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
——————————————————————————————— -----Original Message-----
From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Don Hacherl
Sent: Friday, April 27, 2012 17:20
To: activedir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LVR/Legacy Group Membership Not quite. Think of the version store not as holding VALUES, but rather as holding CHANGES. If you remove Tom then your final list would look like: Dick - LEGACYHarry - LEGACYCurly - LEGACYLarry - LEGACYMoe - LEGACYBob - PRESENTAlice - PRESENT With Tom simply no longer being there. During the update, however, the version store would hold the following: REMOVE TomREMOVE DickREMOVE HarryREMOVE CurlyREMOVE LarryREMOVE MoeADD DickADD HarryADD CurlyADD LarryADD Moe To make it worse, the version store is shared among all database updates currently in flight. An operation may fail or succeed depending on what else is going on in AD at the same time. If it were me (and it was in the distant past), I would delete all the legacy members in a single operation, LET THAT CHANGE PROPAGATE TO ALL REPLICA DCs, and then start re-adding the members. That way you've reduced the size of the biggest operation from "delete 8000 and add 7999" to "delete 8000". Don Hacherl -----Original Message-----From: activedir-owner@xxxxxxxxxxxxxxxx[mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Adam ThompsonSent: Friday, April 27, 2012 7:28 AMTo: activedir@mail.activedir.orgSubject: Re: [ActiveDir] LVR/Legacy Group Membership Thanks, Jorge. So going back to my theoretical group membership: Tom - LEGACYDick - LEGACYHarry - LEGACYCurly - LEGACYLarry - LEGACYMoe - LEGACYBob - PRESENTAlice - PRESENT After removing 'Tom', the list would look like this: Tom - ABSENTDick - LEGACYHarry - LEGACYCurly - LEGACYLarry - LEGACYMoe - LEGACYBob - PRESENTAlice - PRESENT ? If so, when the change is implemented on the DC - would it then have to load the entire list of legacy members into memory, remove 'Tom', add him back in(LVR) as 'ABSENT' and then write the LVR and legacy group membership to the DIT? Thanks again, Adam. On 27 April 2012 14:52, Jorge De Almeida Pinto <jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:> For any linked attribute, and especially multi-valued linked > attributes, the changes (both adds and removes) to the attribute in > terms of storage and replication will leverage lvr as soon as that > change occurs after ffl is> w2k3 or higher. This also applies to values established before ffl isw2k3.> With legacy values you will see that the usn and version of a linked > attribute does not change anymore, but rather the usn and version of > the value changes.> You can see the latter with:> Repadmin /showobjmeta dc "dn if group"> > Legacy values will show as legacy.> > Added New values will show as present.> > Remove new values will show as absent for the length of the tombstone > lifetime> > > Met vriendelijke groet / Kind regards, Jorge de Almeida Pinto> Tel.: +31-(06)-26.26.62.80> (Sent from my Windows Phone)> ________________________________> From: Adam Thompson> Sent: 2012-04-27 14:48> To: activedir@xxxxxxxxxxxxxxxx> Subject: Re: [ActiveDir] LVR/Legacy Group Membership> > Hi Jorge,> > Many thanks for your reply.> > It appears to happen when a 'legacy' member is removed from one of > these groups.> > My understanding was that removing a member from the non-LVR > membership list would still cause the entire non-LVR list to be > replicated.> > For example, a group has the following members:> > Tom - LEGACY> Dick - LEGACY> Harry - LEGACY> Curly - LEGACY> Larry - LEGACY> Moe - LEGACY> Bob - LVR> Alice - LVR> > Removing Bob or Alice (or adding a new member) will mean LVR is used.> > Removing 'Tom' will cause the entire legacy group membership to be > replicated.> > > Or have I misunderstood this?> > I've been going on this:> > http://www.windowsitpro.com/article/domains2/q-how-are-active-director> y-ad-security-group-memberships-replicated-between-different-domain-co> ntroller-dc-ad-instances-does-ad-handle-replications-differently-in-wi> ndows-server-2003-than-in-windows-2000-> > Which says: "After you upgrade your AD forest to Windows 2003 and > switch its functionality level, legacy groups can still cause group > membership change losses. Also, those groups' memberships will still > be replicated using the legacy attribute-level replication mechanism."> > But I'm not able to find something on> Technet/MSDN/support.microsoft.com which says the same sort of thing.> > > Thanks,> > Adam. --AdamTГладна мечка хоро не играе.A hungry bear doesn't dance. List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx
| | | |
|
|