Re: Strange ADAM behavior

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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?


.

Relevant Pages

  • Re: question(s) re: win32::ole and active-directory interaction
    ... I have attached a module I wrote to simplify ADSI queries. ... our $ADSILastErr = ''; ... =head1 VERSION ... Gets all members of a group, ...
    (comp.lang.perl.modules)
  • Re: question(s) re: win32::ole and active-directory interaction
    ... You should be able to get the basics of ADSI over Win32::OLE by looking at the code. ... our $ADSILastErr = ''; ... =head1 VERSION ... Gets all members of a group, ...
    (comp.lang.perl.modules)
  • Re: NetQueryDisplayInformation Question
    ... > enumerating information from Active Directory its self rather than having ... > connecting to the local machine and finding out who the members are of its ... > Would the ADSI still work for me in this situation? ... one is the LDAP provider the other is the WinNT provider. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Strange ADAM behavior
    ... While we do have some groups that have more than 1500 members, ... software and adsi edit. ... something to do with the replication. ... >> We have an adam instance that is replicated to another adam. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Strange ADAM behavior
    ... we can see this same behavior through a third party user management software package for groups with only about 20 or 30 members. ... 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. ...
    (microsoft.public.windows.server.active_directory)