I have many Win 95 clients logging onto a domain where the login script attempts to map drives to shares in a trusting domain. Formerly, these Win95 PC's logged on directly to the "trusting" domain (with a simple .BAT logon script; I'm attempting to implement a multiple master-domain). There are user accounts with the same name in both domains as a transitionary measure (which I'm sure doesn't help) which may or may not have the same password (and which may or may not be causing the problem).The results of the logon script when users logon to the trusted domain are a mixture of:
1. All OK.
2. Script executes but access denied (error 5?) when use x: "\\xxxx\x" done
3. Script executes but claims user is not a member of global group which would cause drives to be mapped.
4. Cant find Kixtart script.
Users have "LogonScriptLauncher.bat" named as their logon script, which simply calls KIX32.EXE <scriptname>. The KIX32.EXE, KIX??.DLL and KXRPC.EXE files and the KIX RPC service are on all domain controllers.
I've copied the KIXTART run-time files to each PC so I might cut down the load/run time in future.
The problem became less prevalent when I added the KXRPC service to each DC however, much to my dismay, it still occurs.
There's a kixtart.ini on each domain controller giving the appropriate search order for RPC stuff.
Suffice to say the problem does not occur under NT Workstation, but it will be next year before all client PCs are running that OS.
Do I need the update for the MSNET32.DLL or have I missed something obvious? (if so how do I get it, it's not on technet).
I'm desperate for a solution; I've had to bin an upgrade weekend to 260 PCs because of this eratic behavior.
Regards,
Ian Taite MCSE
ICL
