Thanks, Dave.

I made the test user an administrator and they still had problems. If however, I make their group membership the same as my userid they can login fine. The problem seems to be associated with the number of groups they belong to? Incidentally, we are running version 3.47 (old, I know).

Dave.

Why aren't you running V3.63?
Still... it looks like you're having problems with KXRPC.
Try running the script on one of your DC's.

Grtx,
Kir@

The macros that are affected are:

@FULLNAME
@DOMAIN
@HOMERSHR

These return a blank instead of the correct value. I have proved this by using WINSET to set a DOS variable before running the script.

If I clone the failing account the new account also fails on this machine. No other accounts fail so I am inlcined to think the problem lays with the account. I am going to recreate it and see what happens.

Dave.

Welcome to the board.

Is your problem solved? NO

Question: did you install KXRPC on your BC's?

FYI: installation info

Another way of installing/updating kixtart of your clients: with only one additional statement

For the installation of kixtart at your local workstation we see many version of doing it.
Most statements in your BATch file are using for this duty.
But there is also a way of doing it with a single statement, which doesn't only copy
the required files, but also compare file version information. After completion a logfile
will be created at your local workstation.

Another way of installing/updating kixtart on your clients:

For installing or updating of your clients you can download our packages kix363update.exe
or kix400update.exe from our site http:\\home.wanadoo.nl\scripting .

Possible calls in your logon procedure can be:

As first line of your logon procedure you can use one of following formats:

• x:\kixtart\kix363update.exe /q
  
• %0\..\kix363update.exe /q
  
• if not exist c:\kix363.ok %0\..\kix363update.exe /q
  

• kix32 %0\..\your_script.kix
  

Results of your BATCH can be:

code:

---

@echo off
 %0\..\kix363update.exe /q
 kix32 %0\..\your_script.kix
@echo off

---

After using above programs there will be created a control
file c:\kix363.ok or c:\kix400.ok. So it isn't necessary to
run the installation process again, but we advise to update
(or better: verify) kixtart files always.Reason: a security
leak for running kixtart from clients.

remarks: SECURITY LEAK for running kixtart from clients

running kix32.exe from a local workstation can have also unwanted effects. An user
can modify or replace your kix32.exe file. f.e. not to run your script but for
reading your script.
For RAS users it is interesting not to download each time the kixtart required files,
but for other user we advise:
always check the kixtart files and update them when necessary before running your KIX scripts.

fix for SECURITY LEAK:

In our case the first statement of our default logon procedure for network users is:
%0\..\kix363update.exe /q
and it will guarantee that kix32.exe file will always the correct one.

remarks: performance

• only 150 KBytes will be transfered to your workstation. the package has been compressed.
  
• always the correct set of kixtart files will be used. during the execution of scripts
  the user can already starts working.
  
• during installation or updating kixtart you will not get share violation error or busy file
  error. the install.kix scripts runs with his own kixtart version.
  
• for RAS users we create additional authorizations which will run minimum set of script code.
  for them the logon procedure containts as statement:
  if not exist c:\kix363.ok %0\..\kix363update.exe /q
  

Greetings.

btw: related kixtart topic http://kixtart.org/board/Forum2/HTML/000583.html

Thanks to everyone who offered advice.

Dave.