Missing ccsw32.dll error with GW7.0.1 ir1 client when NW Client is installed
Shivaji Samanta
forum.
I am having the issue with more users, and it is definitely tied
to the Novell Client, as it goes away if you uninstall the Novell Client
(which is not really a solution). Yes, I have tried the latest 4.91 sp3
client and it makes no difference.
Do I need to open an incident ? I cannot believe no one else is having this
problem, as we have seen it in over a dozen cases so far.
*********************** Original Posting******************************
Updated my GroupWise 6.5.6 system to 7.0.1 ir1 over the holidays. My client
update worked fine on my workstation and laptop. Now that everyone is back
after the break I have over half a dozen clients which will not load the
updated client at all, or will load it only after an error message regarding
"missing ccsw32.dll".
I have tried everything, including all suggestions in TID 10097676 but
nothing works, and I have had to go back to the GW 6.5.6 client for now.
Any ideas ?
TIA
--
Shivaji Samanta
Wytheville Community College
Rolf Lidvall
This error indicates there is a problem with nwsso.dll, see:
"Error: CCSW32.DLL not found launching GroupWise client."
http://support.novell.com/docs/Tids/Solutions/10097508.html
When you select the "Enable single sign-on" option the GW Client will look
for nwsso.dll:
http://www.novell.com/documentation/gw7/gw7_admin/data/abn8sci.html#aboq3al
"IMPORTANT:Novell Single Sign-on must be installed on the user's workstation
in order for this option to take effect."
If you are not using NMAS or "Single sign-on" then you could try to deselect
"Enable single sign-on" in the Post Office Client Options settings and see
if that helps.
Regards
Rolf Lidvall
Swedish Radio (Ltd)
Shivaji Samanta
TID 10097508 does not help, as it has the same suggestion regarding
nwsso.dll as TID 10097676 mentioned in my post.
I do think, however, that you may have hit on something with your point
about the GW Client option setting for Single Signon. We actually had a
license for the Novell SSO product some years ago, and I had set up default
SSO options for the client at the PO level at that time. If this is indeed
the problem, it is strange that it is coming to light only with the GW 7
client now, and that it does not happen when we roll back to the GW 6.5.6
client.
In any case, I have disabled the SSO option for the GW Client at the PO
level, and will report back on how that works with my users when they login
to the system tomorrow morning.
Thanks again,
--
Shivaji Samanta
Wytheville Community College
"Rolf Lidvall" <rolf.l...@sr.se> wrote in message
news:OzNqh.837$Sz4...@prv-forum2.provo.novell.com...
Rolf Lidvall
> There's no adverse consequences to this that I know of, if you are not
> using SSO.
NMAS is also using this file.
Devon Heaphy
fixed it. We think we broke it with something else.
Cheers,
Devon
Patrick Farrell
Good to know. We're not using nmas either which explains why we haven't
seen the issue. We were having it with GW 6.5, but with the newer
client32 and GW (currently 4.91 sp3 and 6.5.7) it works fine without
removing that client.
Patrick Farrell
> Rolf,
>
> TID 10097508 does not help, as it has the same suggestion regarding
> nwsso.dll as TID 10097676 mentioned in my post.
>
> I do think, however, that you may have hit on something with your point
> about the GW Client option setting for Single Signon. We actually had a
> license for the Novell SSO product some years ago, and I had set up default
> SSO options for the client at the PO level at that time. If this is indeed
> the problem, it is strange that it is coming to light only with the GW 7
> client now, and that it does not happen when we roll back to the GW 6.5.6
> client.
>
> In any case, I have disabled the SSO option for the GW Client at the PO
> level, and will report back on how that works with my users when they login
> to the system tomorrow morning.
>
> Thanks again,
>
You could also just delete the nwsso.dll file in the system32 folder.
Rolf Lidvall
> level, and will report back on how that works with my users when they
> login to the system tomorrow morning.
Please do, in fact we disabled this setting only a week ago because we are
implementing NMAS and was getting this issue (GW 6.5):
"It's time to put back the GroupWise client option of "No password required
with eDirectory""
http://support.novell.com/docs/Tids/Solutions/10100049.html
Not only did the "No password required with eDirectory" setting disappear
from the Client, but (since we don't have SSO?) I experienced some strange
behaviour if I checked the "Use Single Signon" option and then changed
password from the Client. So, we decided to just disable this setting, since
we don't use SSO anyway. So far we have not experienced any problems at all.
In fact I notice a slight decrease in GW login time.
> Thanks again,
No problem at all.
Rolf Lidvall
> from the Client,
I forgot to mention that deselecting "Enable single sign-on" on the PO,
does make the "No password required with eDirectory" option visible
again on the Client, even when the nwsso.dll is present. This indicates
that if you deselect "Enable single sign-on" then the Client will not "look"
for that file.
Rolf Lidvall
> nwsso.dll as TID 10097676 mentioned in my post.
I just wanted to show you the connection between the files,
I think that disabling a product by renaming a file is a real
bad solution, I would never do that.
If you don't want a product, like NMAS, NICI, NetIdentity etc
you simply don't install it. Experimenting with deleting certain files
is not a serious solution to an issue in my opinion, no matter if it's
mentioned in a TID or not.
Rolf Lidvall
I installed the NWClient 4.91 SP2 without NICI
and NMAS and it installs the nwsso.dll anyway.
We upgraded to 4.91 at the same time we implemented
NMAS so wronlgy presumed the file came with NMAS.
The properties on the file says:
Novell SecretStore NCP Client Service, so I guess
it's used by the "Single sign-on" option. On the
"Single sign-on"-tab in the Client settings there
is a SecretStore logo.
This constant renaming of Novell products is very confusing.
Sorry about this :-(
Rolf Lidvall
> fixed it. We think we broke it with something else.
CCSW32.DLL comes with NICI:
"Layman's Guide to NICI"
http://support.novell.com/docs/Tids/Solutions/10066559.html
"2.2.2 CCSW32.DLL"
NICI versions newer than 2.x have a DLL named CCSW32.DLL. These are the FIPS
140 level 1 and level 2 certified modules. Refer to the security policy
document for more on the FIPS 140 evaluations. Note that simply copying the
DLL into a directory does not make NICI operational as it requires Windows
registry and configuration file setup. Additionally, NICI module self
verifies itself, hence most components are coupled with the distributed DLL,
and usually are not distributable alone. NICI does not depend on directory
services to be installed."