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

You also mentioned that you have users who have multiple logins on different Domains. I have heard this does create problems. Solution is to change them over to the new NT Server, and delete the other account.

Hopefully these tips or patch files will correct your problem, good luck.

Things to watch out for.
1. Variables longer than 14 characters will be truncated in the kixtart script
2. Watch out for long files names for batch files. Remember DOS sees 8.3 characters.
3. Use the SET command in the batch file. This forces the kixtart program to be executed on specific NT Servers that have the KIXRPC service installed.
SET KXRPC=\\Server_name1, \\Server_name2
4. Create an KIXTART.INI file and place it in the C:\Windows and NETLOGON directories
[KXRPCMapping]
;MyDomain=\\MyServer1,\\MyServer2 \\MyDomain=\\KXRPC_Server Default=\\KXRPC_Server

Default= is used for all unknown Workgroups or Domains to a specific KXRPC server
5. No spaces in the User Manager account details profile.
6. Copy KIX??.DLL to the C:\Windows directory and also include KIX32.EXE. Will speed up login script performance and corrects timeout issues.
7. If you had previously installed Novell Client on the workstation, do the following:
Change the Primary Network Load Order to Microsoft Client in Control Panel\Network
Modify the following in Regedit
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSNP32\Network Provider CallOrder[00 00 00 40] to [00 00 00 20]
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NOVELLNP\Network Provider CallOrder[00 00 00 20] to [00 00 00 40]
8. Use WINSET instead of SET
9. Install the KXRPC service on all NT Servers that are connected to the Domain
10.Make sure that you are using the correct version of DLL's, KIX32.EXE and KXRPC.EXE
11.NETLOGON directories are not setup as shares
12.DirSync is not working properly, so the script and batch files are not replicating correctly.

The network provider registry changes have been applied. Directory replication is not used; changes to NETLOGON scripts are manually copied and all are identical. Yes we do have the Novell Client 32 (read kiss of death) I think it's version 2.5.

I initially thought my problem was with the KIXTART.INI entries. Should the domains be prefixed with '\\'? as per your mail? the kixtart manual doesn't show domains prefixed in such a way.

I also think the KIXTART.INI entries mean workgroup as well as domain.

To expand on the detail already posted, I have two domains - 'BMCEN01' is an account domain and 'BMFIN02' is a resource domain. The Windows 95 PCs have their workgroup (in Network Properties) set to 'BMFIN02' and their computer names are FIN02CWxxxx where xxxx is a sequence number.

The logon script seems to work more reliably when the workgroup is set to BMCEN01 (i.e. the same name as the domain to which they're logging on) instead of BMFIN02. When the workgroup is set to BMFIN02 , the PDC of the BMFIN02 domain, \\FIN02PC seems to be the RPC server ( @RSERVER = \\FIN02PC ) even though this is not mentioned in the KIXTART.INI file located in the NETLOGON share of the BMCEN01 domain controllers (\\CEN01PC, \\CEN01BCIIS01 and \\CEN01BCEXC01 respectively). I've not used the registry setting for the RPC server, nor used the environment variable. In this case, INGROUP('xxx') sometimes work during the logon script, but never work once logged on as the script is looking at groups in the BMFIN02 domain.

Up until tonight, the \\FIN02PC server wasn't running the KXRPC service however it's neither more or less reliable with the service running on this server. At the moment, it's stopped.

I will probably specify 'BMCEN01' as the workgroup name instead of 'BMFIN02' even though this breaks the naming standard.

Do you think I'm barking up the wrong tree here?

Ian.

I am little confused how your network is setup.
Is the \\BMCEN01 the PDC and \\BMFIN02 is setup as a Stand-Alone server ?
Do you have any BDC that are connect to the same domain as the \\BMCEN01 server is in ?
If this is the case, workstations (Win95 clients) that connect to the \\BMCEN01 domain will always send requests to the \\BMCEN01 server to be validated, and it will check to see if the account is in either a global\local group on that domain.
If the \\BMFIN02 is a Stand-Alone server is it involved in a domain or workgroup ?
If it is in the workgroup then the NETLOGON dirsync will have errors because it is not a part of the domain, which will create errors on executing the login script about missing files.
Have you tried specifying the mappings as follows IF INGROUP("<domain>\<group>") ?
If you can run the Kixtart script manually from the NETLOGON shared folder without any Kixtart errors then the problem is related to the servers and how they are communicating to each other.

I am little confused how your network is setup.
Is the \\BMCEN01 the PDC and \\BMFIN02 is setup as a Stand-Alone server ?
Do you have any BDC that are connect to the same domain as the \\BMCEN01 server is in ?
If this is the case, workstations (Win95 clients) that connect to the \\BMCEN01 domain will always send requests to the \\BMCEN01 server to be validated, and it will check to see if the account is in either a global\local group on that domain.
If the \\BMFIN02 is a Stand-Alone server is it involved in a domain or workgroup ?
If it is in the workgroup then the NETLOGON dirsync will have errors because it is not a part of the domain, which will create errors on executing the login script about missing files.
Have you tried specifying the mappings as follows IF INGROUP("<domain>\<group>") ?
If you can run the Kixtart script manually from the NETLOGON shared folder without any Kixtart errors then the problem is related to the servers and how they are communicating to each other.

I am little confused how your network is setup.
Is the \\BMCEN01 the PDC and \\BMFIN02 is setup as a Stand-Alone server ?
Do you have any BDC that are connect to the same domain as the \\BMCEN01 server is in ?
If this is the case, workstations (Win95 clients) that connect to the \\BMCEN01 domain will always send requests to the \\BMCEN01 server to be validated, and it will check to see if the account is in either a global\local group on that domain.
If the \\BMFIN02 is a Stand-Alone server is it involved in a domain or workgroup ?
If it is in the workgroup then the NETLOGON dirsync will have errors because it is not a part of the domain, which will create errors on executing the login script about missing files.
Have you tried specifying the mappings as follows IF INGROUP("<domain>\<group>") ?
If you can run the Kixtart script manually from the NETLOGON shared folder without any Kixtart errors then the problem is related to the servers and how they are communicating to each other.

All the above have the 3.6 kix??.* files plus the kxrpc.exe in their netlogon shares and are running the KXRPC service.

The Win 95 PCs have 'BMFIN02' set as their workgroup however, the Microsoft Client for Microsoft networks is set to log the user on to the 'BMCEN01' domain and restore network connections.

My test PC has the MSNET32.DLL patch applied and the two registry changes you mentioned re network provider order.

In this scenario, will the RPC server be once of the servers from the BMCEN01= line, because that's the domain the client is loggin into, or will the RPC server be from the BMFIN02= line as that's the workgroup the PC is a member of.

The way the script behaves during logon is different to when the script is run after being logged on, and this is making it very difficult to test in a consistent manner.

As a work around, I might get rid of the KXTART.INI file and place a SET KXRPC=\\CEN01??????? statement in my LogonScriptLauncher.bat file to force KIX to use whichever domain controller KIX is started from. I know according to the manual that's what KIX is supposed to do anyway, but there's something else going on here.

What really stands out is MS Article Q100011
User Name Duplication
There should not be user name duplicates on different domains. If a user name is duplicated across different domains, there will be inconsistent results when a logon is attempted from a Windows for Workgroups workstation on that Windows NT network.