In order to eliminate all other factors tests were run using one line script, which simply outputs the result of the INGROUPS() test. You can't get much more basic than that.

Any ideas anyone?

Could you post the line that you have tested with?

I suppose you use INGROUP and not INGROUPS as you have posted above?

------------------
Greetz,

Roger the Young
------------------------
The code is out there...
------------------------
http://home.wanadoo.nl/r.s.m.s.dejong/Kixtart

------------------------

[This message has been edited by DrillSergeant (edited 01 February 2001).]

SPD

I could be a KIXRPC-service related problem IF he only tried it on Win9x machines, but as he said he also tried it on a WinNT machine and those don't need KIXRPC-service.

I've promised I won't mention a certain document any more about KIXRPC, but if you look below at my sig

------------------
Greetz,

Roger the Young
------------------------
The code is out there...
------------------------

http://home.wanadoo.nl/r.s.m.s.dejong/Kixtart

------------------------

A short story about KIXRPC

Fuse - Could you post a line or two of your code with the ingroup statement that you're using?

Are the groups that you're looking for local or global groups?

------------------

"He was a good little monkey and always very curious..."

Sorry about the typos. I'm using INGROUP, not INGROUPS.

KIXRPC is running on all logon servers.

I'm home right now, so can't even grab a copy of any of the scripts I've tried. However, the offending test line is always something as simple as:
IF INGROUP("Administrators")

The tests have been with all upper, all lower and mixed case, even though it's not supposed to matter. (I was desperate.)

I also tested for actual return values of 0, 1 and 2, although all I really need is any non-zero value.

By placing a PAUSE command in the calling batch file I was able to view the output and no script errors were reported.

I have tried testing for both local and global groups.

Sarge, http://home.wanadoo.nl/r.s.m.s.dejong/Kixtart was a dead link when I tried it a few moments ago. I'll try again later.

I think taht pretty much covers the questions asked so far. Once again, any ideas?

Ok, back to your problem... How are the other common macros (like @USERID, @WKSTA)
If they are fine, how are the more exotic ones (@LDOMAIN, @HOMEDRIVE)?

And the one question you forgot was: Wich version of KIX do you use?

------------------
Greetz,

Roger the Young
------------------------
The code is out there...
------------------------
http://home.wanadoo.nl/r.s.m.s.dejong/Kixtart


A short story about KIXRPC

------------------------

[This message has been edited by DrillSergeant (edited 02 February 2001).]

When you said that it doesn't work for commands like this

IF INGROUP("Administrators")

is this a local oe global group?

typicaly the Administrators groups is a local group.

For local groups it is always best to place the computername before the group name.

example:

if ingroup("@wksta\administrators") = 2
? "You are in the local Administrators group on @wksta"
endif

Bryce

I did forget to mention the KIX version in the first reply but got back soon after and posted another - version 3.63 was the answer.

The @USERID and @WKSTA macros work fine, as do @LDOMAIN and @HOMEDRIVE.

Bryce:
As mentioned, I tried the command on both local and global groups. I certainly wouldn't place the workstation name before a domain group, as that is neither relevant nor correct. However, I did try the command with the domain name before the group but that didn't work either.

Is the group that you are having trouble with "administrators"?

will ingroup work with any or your other global groups?

By default the "administrators" is a local group, and all domain controllers share the same local/global groups.

In this case you would want to specify the computer name (the authenticating domain controller) using @lserver

if ingroup("@lserver\administrators") = 2
? "You are in the local administrators group on @lserver"
endif

Bryce

[This message has been edited by Bryce (edited 05 February 2001).]

This one function consistantly fails, regardless of the OS on the client machine. This puzzles more all the more because other commands and functions all function correctly, or at least those I've tried. Admittedly some don't work quit as I first expected but they do work.

Out of pure desperation I have even downloaded and installed a fresh copy of Kixtart, all to no avail.

If this failure of INGROUP only occured on a single server I could understand that there is a problem but in this case there are 6 logon servers, all giving identical results.

How are you determing whether this portion is returning a value of zero? Does the script resolve the group memberships properly in other ways (drives mapped, etc), but appears to always return a value of zero?

For example, if your script is:
IF INGROUP = ()
IF @ERROR = 0

Using '@ERROR' on "IF INGROUP" will properly return a zero every time if the "IF INGROUP" script is correctly formatted and executed.

If using a variable substitution, such as
$RC = INGROUP ()
? $RC

Then the variable $RC should properly return a value of 0, 1 or 2 depending upon group membership.

Hope this helps.

Bill

Your example of IF INGROUP = () is not correct but I figure that was a typo.

Here's a small snippet from my script:
;
; Exit if this is an R&D user
;
if ingroup("R&D")<>0
exit
endif

All I'm testing for the whether or not the user is a member of a group, be it local or global. It just doesn't get more basic than that. Of course my problem is that (for me) the INGROUP test ALWAYS returns zero, no matter what.

I've used several methods of determining the results, including single stepping the code, adding debug code and sending the results to either a file or the screen, etc. There is no doubt, no ifs or maybes. The function always returns a zero.

When making changes I first run the script via the command line on a client machine to ensure there are no syntax errors. I then upload it to the PDC and wait for it to replicate to all BDCs (I get a message when this happens) prior to logging off and on again to see what I get.

As to the other part of your reply, the behavior of the script is correct for a result of zero, so it's not as if it was performing correctly but looking wrong (although it was certainly worth asking).

For instance, the part of the script quoted above never causes the script to terminate, even if the user is in the R&D group. If I use the INGROUP() function for drive mapping, which is one of the things I want to do, nobody gets any drives mapped.

As part of my testing I have created several groups, both local and global, and put myself in them.

Anyway, I'm stumped based upon snippet you provided. My tests of same structure, when executed from the command line, return proper reply based upon group memberships.

Command line test was simple messagebox display - IF INGROUP (A) <> 0, etc., and proper messagebox displayed every time.

Also added a test group 'R&D' in my domain, edited login script for drive mapping, and login script executed properly. I thought the '&' in group name might be an issue, but does work properly for me so apparently not.

Perhaps the issue is code prior to execution of this section, and the error not surfacing until this section? Don't know, just fishing now.

Bill

I've considered all the same possibilities. The R&D group is of course only one of the groups. As it happens, it's the only one with something other than pure alpha characters.

To eliminate the possibility of any kind error earlier in the script causing the problem I have run test scripts with nothing before the INGROUP test. Same results.

What bothers me most is the fact that this function apparently works for everyone else in the world. I could understand if other commands or functions failed but they don't.

For now at least I'll use the resource kit utility to work around the problem. If I ever do find the cause I'll make a point of posting it.

Thanks to everyone who took the time to think about it but unless someone else can duplicate the problem I think we'll leave it there.

Good luck.

Bill

I hate to see this problem go unfixed, so if youe could, could you please post a copy of your logon script?

Bryce

[This message has been edited by Bryce (edited 09 February 2001).]

I'm thinking this might have something to do with domain trust and pass-through authentication, etc...

I would go back to basics and start small - set up local workstation accounts and add them to local workstation groups - get that to work - then add domain users to local workstation groups and check for that... keep building until something breaks....

Don't bother trying to debug Win9x until you get WinNT working (eliminate KXRPC as a problem source )...

What kind of domain structure do you have ? Are you workstations joined to the logon domain or are they joined to a resource domain ?

Shawn.

Fuse - you said that you are using a resource kit tool that will give you a group listing? Wich tool is that?

If a simple tool can retrieve the group listing, Kix should be able to do it too.

------------------
Greetz,

Roger the Young
------------------------
The code is out there...
------------------------