Les, good catch on the ‘S’, that’s what happens when you try to joking after banging your head against the wall until 3 in the morning…

I am encouraged by the fact that so many other sites are using the INGROUP function without a problem, I to expect to find the solution to our issue and post it.

Is the group cache local to the PC or pulling it from the GC? Do you know where can I get more information on checking and repairing this cache? Is there a way to determine where kix is getting this information? The logon server is displayed, but I do not believe this is where the information is pulled from.
- We tried to rename ‘test-groupa’ to ‘test-groupb’ just to see if that may have contributed to the problem – I don’t have the results yet.
- The logon server returned is DC1.
- Using ‘AD users & computers’, connecting to DC1, searching for ‘test-groupa’ results in “no items match…”, searching for ‘test-groupb’ is successful,
- Using the test script still shows ‘testuser’ in ‘test-groupa’ and not in ‘test-groupb’ after 2 hours and a ‘testpc’ reboot. This may be a replication issue, but normal replication in our network is 45 minutes and monitored pretty well.
Right now I’m leaning towards a cache issue.

I verified the quotes, spaces, missing endif’s, etc. the test code is clean. I kept it simple to minimize these problems.

I’m using Kix version 4.22

What is considered an optimized network configuration? My test clients and DC are using the same switch and subnet.

The ‘problem’ group name was short 3 letters dash three letters, no spaces. There were other groups that had a problem, but they turned out to be DGs not SGs or had spaces that were not accounted for in the script. Other groups with dashes work fine.

I did add the following to the code:
Code:

$index=0
$Global=""
DO
$GGroup = ENUMGROUP($index)
$Global=$Global+@CRLF+$GGroup
$index=$index+1
UNTIL Len($GGroup)=0 
? "Global Groups : "+$Global

This allows me to compare the Global groups from ENUMGROUP with the INGROUP test, further minimizing the ‘fat finger’ syndrome as the problem. So far the results are consistant. The user is either 'in both' or not 'in both'.

There are a couple of domains in our net, but nothing messy …
W2k native with an empty Root and 1 Main user and resource domain – the one we are working in for this problem.
4,500 desktops and 30 DCs across the US.
I still think the issue may reside with the cache…

Thanks,
Mike