Re: Strange ADAM behavior
- From: "Joe Kaplan \(MVP - ADSI\)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 3 Apr 2005 16:36:50 -0500
I assume that no exception is getting thrown in your .NET code, right? The
CommitChanges works but the changes simply don't go through?
In that case you have a pretty weird problem. Replication could conceivably
be part of the problem, but I really don't know. Perhaps Joe, Lee or Dmitri
will have an idea what to look for or what tool to use to diagnose this. A
network trace of the problem as it occurs would also be helpful, but that
might be hard to come by.
Joe K.
"lam784" <lam784@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E5FACF46-0525-4E99-85ED-3991A223220E@xxxxxxxxxxxxxxxx
> While we do have some groups that have more than 1500 members, we have
> other
> groups that have only a few members that are displaying the same behavior.
> Additionally, we can see this same behavior through a third party user
> management software package for groups with only about 20 or 30 members.
> Once we "force" a user into a group in question through ldif, then it's
> like
> the group is cleared up and works correctly both through the third party
> software and adsi edit. It really seems volume related in that if we push
> a
> large amount of data into the adam through a custom .net program that is
> using directory services then we will see this behavior in the groups.
> It's
> like the data is not been committed to the group and are wondering if it
> has
> something to do with the replication. Any ideas?
>
> "Joe Kaplan (MVP - ADSI)" wrote:
>
>> If the groups have more than 1500 members, then ADSI won't return all of
>> them without using attribute ranging. So it could be the case that the
>> members are in the group, but that you just don't see them.
>>
>> Ldp.exe allows you to do range retrieval graphically so you don't have to
>> write code for this. Just do a base-level search on the group and use
>> the
>> syntax "member;range=1500-*" to see the next group (quotes included).
>> You
>> keep increasing the first number by 1500 until you see all the members.
>>
>> Joe K.
>>
>>
>> "lam784" <lam784@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:643A714F-6838-4139-A938-1E053562E49F@xxxxxxxxxxxxxxxx
>> > Hi,
>> > We have an adam instance that is replicated to another adam. We have
>> > begun
>> > seeing strange behavior around groups and large transactional updates
>> > of
>> > adam
>> > data. After running a large batch update that will "successfully"
>> > complete
>> > we will see that there are some groups that don't appear to have
>> > particular
>> > users as membership in them. When you try to add that user to the
>> > group
>> > through a third party application it appears that it adds successfully
>> > but
>> > when you view the membership through adsi the user is not there. If you
>> > add
>> > the user to the group through adsi it tells you the user is already a
>> > member
>> > of the group even through you don't visually see them. You can force
>> > the
>> > user into the group by adding them with an ldif but that is the only
>> > way.
>> > It's like the membership data for the group is in a quasi uncommitted
>> > state.
>> > We feel like it may be due to large volumes of transactional data -
>> > replication can't keep up and the adam sort of chokes, but we have not
>> > been
>> > able to prove or disprove the relationship to replication. Had anyone
>> > seen
>> > this type of behavior before?
>>
>>
>>
.
- Follow-Ups:
- Re: Strange ADAM behavior
- From: lam784
- Re: Strange ADAM behavior
- References:
- Strange ADAM behavior
- From: lam784
- Re: Strange ADAM behavior
- From: Joe Kaplan \(MVP - ADSI\)
- Re: Strange ADAM behavior
- From: lam784
- Strange ADAM behavior
- Prev by Date: Re: Slow client logon
- Next by Date: Re: Slow client logon
- Previous by thread: Re: Strange ADAM behavior
- Next by thread: Re: Strange ADAM behavior
- Index(es):
Relevant Pages
|
