I was given a fix for this which meant disabling the Client Access network provider. IBM have now released a dll (not availablr as a sp yet)which solves the problem:
On a WinNT PC with both Microsoft SMS 2.0 and Client Access XD1
installed, an unpredictable number of users will experience a
problem with the NT login dialog box taking an extremely long
time to come up and then the NT domain is not listed. Then when
the user signs on they aren't fully authorized by NT and will
experience slow performance and NT 'not authorized' messages.
Problem Summary
On a WinNT PC with both Microsoft SMS 2.0 and Client Access XD1
installed, an unpredictable number of users will experience a
problem with the NT login dialog box taking an extremely long
time to come up and then the NT domain is not listed. Then when
the user signs on they aren't fully authorized by NT and will
experience slow performance and NT 'not authorized' messages.
Problem Conclusion
Having Microsoft SMS 2.0 installed changes the load order of a
Windows security component causing it to be loaded earlier
during OS startup. This security component causes all of the
network providers registered with the OS, including the Client
network credentials manager (cwbnetnt.dll) to be loaded at this
time. After following the initial load of the Client Access
network credential manager DLL and all of the DLLs that it has
dependencies on, a hang was discovered where one of these
dependent Client Access DLLs called a Windows API to retrieve
the current user of the operating system. It turns out that
this Windows API is implemented by calling a function contained
in the Windows security component itself. Since this Windows
security component isn't completely started yet (waiting for
the Client Access network credentials manager DLL to load) the
call to retrieve the current user from within a Client Access
DLL (cwbab.dll) causes the Windows security component to hang.
In looking at the Microsoft SDK documentation, updated
information was found (which wasn't in the SDK documentation
when Client Access for Windows NT was first designed) that
does warn against calling the Windows API to retrieve the
current user of the OS during initialization of any DLL. It
warns of unreliable results if this API is called in this
way.
The Client Access DLL that makes this API call during
DLL initialization (cwbab.dll) will be rewritten so it does
not make this call at that time. This revised DLL (cwbab.dll)
will be part of the next service pack available for V3R2M0
Client Access. The revised DLL will allow the Windows
security component to complete the logon process normally.
Temporary Fix
Comments
Circumvention
A temporary fix module (cwbab.dll) will be available on the
IBM ftp site until the service pack that contains this fix
is shipped. The ftp location is:
ftp://ftp.software.ibm.com/as400/products/clientaccess/win32/v3r2m0/files/sa89627
[sig][/sig]
On a WinNT PC with both Microsoft SMS 2.0 and Client Access XD1
installed, an unpredictable number of users will experience a
problem with the NT login dialog box taking an extremely long
time to come up and then the NT domain is not listed. Then when
the user signs on they aren't fully authorized by NT and will
experience slow performance and NT 'not authorized' messages.
Problem Summary
On a WinNT PC with both Microsoft SMS 2.0 and Client Access XD1
installed, an unpredictable number of users will experience a
problem with the NT login dialog box taking an extremely long
time to come up and then the NT domain is not listed. Then when
the user signs on they aren't fully authorized by NT and will
experience slow performance and NT 'not authorized' messages.
Problem Conclusion
Having Microsoft SMS 2.0 installed changes the load order of a
Windows security component causing it to be loaded earlier
during OS startup. This security component causes all of the
network providers registered with the OS, including the Client
network credentials manager (cwbnetnt.dll) to be loaded at this
time. After following the initial load of the Client Access
network credential manager DLL and all of the DLLs that it has
dependencies on, a hang was discovered where one of these
dependent Client Access DLLs called a Windows API to retrieve
the current user of the operating system. It turns out that
this Windows API is implemented by calling a function contained
in the Windows security component itself. Since this Windows
security component isn't completely started yet (waiting for
the Client Access network credentials manager DLL to load) the
call to retrieve the current user from within a Client Access
DLL (cwbab.dll) causes the Windows security component to hang.
In looking at the Microsoft SDK documentation, updated
information was found (which wasn't in the SDK documentation
when Client Access for Windows NT was first designed) that
does warn against calling the Windows API to retrieve the
current user of the OS during initialization of any DLL. It
warns of unreliable results if this API is called in this
way.
The Client Access DLL that makes this API call during
DLL initialization (cwbab.dll) will be rewritten so it does
not make this call at that time. This revised DLL (cwbab.dll)
will be part of the next service pack available for V3R2M0
Client Access. The revised DLL will allow the Windows
security component to complete the logon process normally.
Temporary Fix
Comments
Circumvention
A temporary fix module (cwbab.dll) will be available on the
IBM ftp site until the service pack that contains this fix
is shipped. The ftp location is:
ftp://ftp.software.ibm.com/as400/products/clientaccess/win32/v3r2m0/files/sa89627
[sig][/sig]
