Thanks for the reply…
This is a W2k native AD domain.
Verified the user info on the specific DC that was used to login as well as the other DC’s
Verified replication as well…
GC communication seems fine.
We are running E2k3 which breaths AD, any hiccup in AD kills E2k3
I have the same problem when the user logs on with DC1, DC2, …, DC30

I also tested the script by running it locally – to avoid the replication delays.

I was following the thread started by myboat245 and ran netdiag - all tests were successfull.

My system admin seems to think the INGROUP function was working fine Tuesday, but that may have been dumb luck as none of the scripts we are running check all of the group memberships for a user.

I’ve noticed a lot of posts on INGROUP problems… I may have to revert back to VB

I was able to find some missing spaces and a couple of Universal Distribution Groups that were not being returned using INGROUP or ENUMGROUP...

I am still stuck on user1 on computer1 being in group A, but the same user on computer2 not being in group A...
NTDOC, you may be right on the replication - I won't be able to test that until tomorrow as the infected users have already left.

I came across
Re: how do you get the string value from 'INGROUP'
#5603 - 07/12/2000 10:37
a post from Roger the Young that had the following code:
$index=0
$Global=""
$Local=""

DO
$GGroup = ENUMGROUP($index)
$Global=$Global+@CRLF+$GGroup
$LGroup = ENUMLOCALGROUP($index)
$Local=$Local+@CRLF+$LGroup
$index=$index+1
UNTIL Len($GGroup)=0 and Len($Lgroup)=0

? "Global Groups : "+$Global
? "Local Groups : "+$Local

I added teh @CRLF to help read the output, so far this has helped isolate the problem…



Edited by mbarnes (2004-05-06 04:50 AM)