When a user logs onto the NT server (users are all Win98) the login script will check if member of group A then run This, else continue with rest of script.

Is that possible? If so how would I do that?

code:

---

IF INGROUP("Domain Users")
    DISPLAY "z:\users.txt" 
ENDIF 

---

For more information, look at the INGROUP function in the manual.

However, if this is all you need to accomplish, you may just want to use IFMEMBER.EXE from the NT Resource kit.

code:

---

IFMEMBER /v "Domain\Domain Admins"
IF errorlevel 1 GOTO ADMIN

---

I hate to sound stupid, but I'm not sure if i need your software to do this or if I can use IFMEMBER from the resource kit.

code:

---

::If user is in NAV Group, install NAV
IFMEMBER /v "YourDomain\NAV Group"
IF errorlevel 1 GOTO NAVUPD
GOTO MAPDRVS
:NAVUPD
::Install NAV
:MAPDRVS
::Map Drives for all users

---

That should get you started. I highly recommend you pick up a book or do some reading on creating batch files if you are still confused.

IF INGROUP("NO_NAV") goto finish ENDIF

code:

---

$Company_PC_List = "Server\Share\Folder\List.txt"
$x=Open(1,$Company_PC_List,2)
$Computer = ReadLine(1)
While $Computer <> ""
    If $Computer = @WKSTA
       ; Computer is company owned, so install NAV
       $x=Close(1)
       Goto NAV_Install
    Else
       ReadLine(1)
    Endif
Loop
Exit
:NAV_Install
; Code to install NAV
Exit

---

If you have a standardized WKS naming convention, a spin on Jeroen's concept could work with less effort. Instead of managing a computer list manually, just search for a common substring within the WKS name.

If you want to do an elegant quasi-SMS software deployment instead of C&D, you could setup an INI file to hold all WKS related config and manipulate that INI file. Sealeopard has an excellent example of that in his post:

HOW-TO: Running scripts with ADMIN powers

Amantica,
I sense you're still at the baby-steps phase of deployment. It may be time well spent to study Sealeopard's implementation for consideration in your setting before building a legacy of haphazard scripts as I have.

I've thought of the name check too, but I'd prefer my method because:

Say your company's naming convention is to name all laptop computers MOB0000 through MOB9999 (MOB being Mobile). You could check if the computer logging on has MOB in it's computername or something, but chances are that people bringing in their own W9x laptop (e.g. Contractors etc) could also be using a computername with MOB in it. You would have to narrow down the check for the computername to f.e. a fixed length or something.

And now straying off-topic:

Say you did build a precise check if the computername is MOBxxxx: If you would also like to prevent privately owned or other outside laptops (with possible viruses, or who knows what on them) from logging on to the network, this check would prevent a lot, but the 'smart users' will be able to read the logon script, and change their computername to fit that of an 'allowed' PC.

(people who would like to get a free copy of licensed software that you roll out using the logon script could use this method.)

I know, it's a long shot, but eversince we had 1 user who figured out a password by reading the logon scripts, we always assume the worst. They say 'assumption is the mother of all f*ck-ups'.

Using a static file prevents most. Users with a private laptop or contractors etc could still use a computername of a PC of a person who is currently on holiday or something, but it would be a lot harder for them to do so.

Hold on:
My paranoide self is taking control; I'll stop this reply before I say you should shut down all servers to prevent unauthorised use !!

My office looks like 'mission control' with multiple computers and monitors, network sniffers, NMS, SMS, etc. No machine connects to my network without me knowing about it.

Didn't someone say that "paranoia is reality on a finer scale" (Movie - Strange Days)?

Our advice (see our input on many virus discussions).

Our organization doesn't accept any PC without an actual virus scanner
on the network.
When we hired personal they had to confirm f.e. our virus and security
policies. Mostly such persons have an additional PC with network
connection. During their project they are a "member" of our company
and they also use our company-wide license of such software.
Another reason we give them another PC is: their organization can't
blame our organization for infecting their organization with a virus.
Greetings.

btw: another element you can use are the IP numbers. For roaming users
we have reserved a specific range of IP numbers and by a logging on
session those machine will be checked for the actual configuration
(f.e. is virus activated and has it an actual update).

code:

---

  
		USE X: "\\NAVSERVER\VPLOGON"
		? "Mapping X:					Status=" + @SERROR
		SHELL "X:\VP_LOG32 /p=X:"
		? "Checking for new version. 			Result=" + @SERROR

---

Most of the sites I've been to say that IFMEMBER only works with NT Workstations. Is that so? All of our workstations are Win98