#119086 - 2004-05-06 02:44 AM
INGROUP problem
|
mbarnes
Fresh Scripter
Registered: 2003-09-18
Posts: 7
Loc: Atlanta
|
Thank you for looking at this problem…
I’m having an issue with the INGROUP function…
In troubleshooting the problem I created a brief IF INGROUP A - G, display YES or NO script. Example:
IF INGROUP("A") <> 0
? "@USERID is in group A <> 0 ..."
ELSE
? "@USERID is NOT listed in group A <> 0..."
ENDIF
We have experienced the following:
TestUser1 logs into TestComputer1
TestUser1 is seen as belonging to Groups A, B, E, F (even though TestUser1 is a member of groups A – G) for example
When TestUser1 logs into TestComputer2 (using the SAME script)
TestUSER1 is seen as belonging to Groups B, C, D, E, G
The group membership results seem to remain consistent on the PC.
Both computers are Windows XP Service Pack 1, although the problem is NOT limited to Windows XP because I have experienced this on Windows 2000 machines also.
I have tried the /f switch with and without the date.
I have INGROUP with and without the domain
I have used single and double quotes
I’m using Kix ver 4.22.
I’m successfully logging into the domain.
The following results are displayed correctly as part of the script output:
? "Name: " @FULLNAME
? "User ID: " @USERID
? "Windows User ID: " @WUSERID
? "Site: " @SITE
? "IP Address: " @IPADDRESS0
? "Date / Time: " @DATE " " @TIME
? "Domain: " @DOMAIN
? "Host Name: " @HOSTNAME
? "Computer Name: " @WKSTA
? "Logon Server: " @LSERVER
? "Windows version: " @DOS
? " " @BUILD
? " " @CSD
? " " @PRODUCTTYPE
? "Primary Group: " @PRIMARYGROUP
? "Privilege: " @PRIV
? "Kix version: " @KIX
Any additional ideas are welcome!
|
|
Top
|
|
|
|
|
#119088 - 2004-05-06 03:28 AM
Re: INGROUP problem
|
mbarnes
Fresh Scripter
Registered: 2003-09-18
Posts: 7
Loc: Atlanta
|
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)
|
|
Top
|
|
|
|
|
#119090 - 2004-05-06 10:38 PM
Re: INGROUP problem
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
|
Maybe not the exact code your looking for, but this code will check which groups/accounts are on the local machine and report them back.
How many DOMAINS do you have as part of your AD? Maybe some other issue of transitive trusts involved even.
All I can say is that we have over 50,000 desktops with multiple Domains around the globe on AD 2000, and so far all of my scripts work just fine with the InGroup call.
Code:
Break On
Dim $SO
$SO=SetOption('Explicit','On')
$SO=SetOption('NoVarsInStrings','On')
EnumLocalGroups('your domain','system to check')
Function EnumLocalGroups($Domain,$System)
Dim $Array,$colGroups,$objGroup,$objUser,$Flag
$Array = "group",""
$colGroups = GetObject("WinNT://" + $Domain + '/' + $System )
$colGroups.Filter = $Array
$System ?
For Each $objGroup In $colGroups
$objGroup.Name ?
For Each $objUser in $objGroup.Members
CHR(9) + $objUser.Name ?
Next
Next
EndFunction
|
|
Top
|
|
|
|
|
#119091 - 2004-05-19 12:39 AM
Re: INGROUP problem
|
mbarnes
Fresh Scripter
Registered: 2003-09-18
Posts: 7
Loc: Atlanta
|
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
|
|
Top
|
|
|
|
|
#119093 - 2004-05-19 08:50 AM
Re: INGROUP problem
|
mbarnes
Fresh Scripter
Registered: 2003-09-18
Posts: 7
Loc: Atlanta
|
I have tried the /F option, with and without the date – same results.
The group name is wrapped in quotes.
The group, user, DC, GC, everything is in the same domain.
The test PCs, DCs and GC and all IP only. There is probably some IPX still floating around, jet directs, etc. But no other protocols other than IP on the systems in question.
I created a new group. I added 2 user accounts to the group.
The script was tested and everything was happy – worked as expected
The group was renamed – looking for the source of the original problem.
Using the same script and the same PC
User1 results are in the group – everything is happy.
User2 results are not in the test group – but is happy with the “domain users” group
For grins I tried the kix32 /F again while logged on as the problem user and guess what – everything is happy! Who knows why it did not work the last time – I suspect user error…
“…Their's not to reason why, Their's but to do and die:…” Lord Alfred Tennyson
So this makes me wonder if it would be good practice to include the /F switch on all scripts?
I'll need to wait until the AM to test on the original problem children... until then Thanks, Very Much So!
Your ongoing help to the board is very much appreciated!!
|
|
Top
|
|
|
|
|
#119094 - 2004-05-19 10:01 AM
Re: INGROUP problem
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
|
Quote:
So this makes me wonder if it would be good practice to include the /F switch on all scripts?
Well that depends on you and how often you change your code. The caching is designed to eleviate traffic to your domain controllers.
If you make a lot of changes then you may want to use it, if on the other hand most of your code is fairly static then not using it will reduce the overhead on the domain controllers.
|
|
Top
|
|
|
|
|
#119095 - 2004-05-19 11:17 AM
Re: INGROUP problem
|
mbarnes
Fresh Scripter
Registered: 2003-09-18
Posts: 7
Loc: Atlanta
|
I don't believe the problem was the code changes, but the object in the GC changed in this case the group name.
I may try to add the flush before some scripts that rely heavily on the GC and monitor the traffic.
Thanks!
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
1 registered
(Henriques)
and 2516 anonymous users online.
|
|
|
