client error: could not register CCIM

[awalsh]

All clients are discovered, but only some show "Yes" under the Client column on the Administrator Console. All machines are on the same domain and use the same subnet mask, so I don't believe I have issues with the boundaries settings. (I have checked the settings and the log files to verify this.)

I've tried both manual and logon client installs on the problem machines and find errors/warnings in the wnmanual.log/wn_logon.log files including "Could not register CCIM," "Could not get executable path from registry," "no abstract export defined for site SM2."

The sms client service is indeed missing from these problem machines. (ie it doesn't show up under computer management/services).

One idea: We have a PDC and a BDC and I've noticed that all of the problem machines I've checked have authenticated through the BDC. (I haven't checked them all.) Some machies that don't have problems installing the client have authenticated through the BDC, too, but most are authenticating through the PDC. Could this be a clue?

Other than that, I'm stuck. I'd really like to get this beast working, but without all clients operating, it's useless to me. SMS promises the moon. I'd like to see it in my lifetime. If you have any ideas of other things to check, you may just change my life.

 

[vulpine]

have you given your sms service account domain admin privileges?
did you alter your logon script yourself - or did you check the 'modify user logon scripts' box in the logon client installation properties? that could be your problem. I found that it was best to do it myself. make sure that the smsls.bat is in the same folder as all of your logon scripts on the pdc and bdc and then modify your user logon script such as:

if $SMS=1
SHELL "%COMSPEC% /E:1024 /C" + "\\yourservername\Netlogon\SMSLS.BAT"
endif


if you had a previous installation of sms running before that could also be it. the logon script will find SMS on there and then skip it.

hope i gave you some new paths to follow - it is a long journey but well worth it.

 

[awalsh]

(Thanks for your feedback and encouragement.)

I'm a bit confused....
If the logon script was the problem, wouldn't the manual install I attempted have been successful? I had the same results/errors/warnings show up on both wn_logon.log and wnmanual.log after trying both client install methods.

And if the logon script wasn't correct, why would the clients be installing on some machines and not others? The machines are all Win2K and are identically built. They are installed in labs all at one time, but are giving inconsistent results. Of course, over time registry changes could be made that might lead to these errors/warnings....

(The sms site service acct has domain admin priviliges = True.)

Thanks again.

 

[snyderj]

Some ideas...

If some devices on a given subnet are becoming clients and some are not then check securities. Are the successes only on devices where users log on with local admin rights?

Check ccr.box for ccr's that aren't being processed (which would cause rights elevation to not occur).

If all of a given subnet are not getting clients then check boundaries. If masking is used be sure to calculate the right boundary using a tool such as

http://www.telusplanet.net/public/sparkman/netcalc.htm.

(enter the mask and ip into the network/node calculator and use the results for network as your boundary.)

Were any SMS folders already on the clients? If so, check permissions on these folders. If Users don't have modify, read, execute and write then you'll need to use xcacls to do a bulk change on those permissions.

 

[awalsh]

Thanks for the ideas.

I have a hunch that it's a permissions issue. I checked permissions on the client sms registry and file folders and haven't been able to find any differences between clients. But I did find another difference: using the same domain admin acct, the problem client gives a "You do not have permissions to do this" error when I try to run smsman.exe /u and a non-problem client does not. The domain admin acct shows up in the local admin group on both computers.

I think I'm getting close. Any ideas to get permissions set up correctly once and for all? If I could copy the settings from a working client to a non-working client I think I'd be set.

 

[vulpine]

The way we did it was create a domain administrator group, add the sms svc acct to that DA group, and then add that DA group to the local Administrators group on each machine. That way you don't have specific accounts in the local admins group (more secure). When managing who has domain admin priviledges - there is only one location to make modifications rather than 1000 machines. We are still on a NT domain - will be moving to 2000 soon - this method makes the transition easier as well.

 

[awalsh]

Let me clarify that our sms site service acct is a member of domain admins. I only brought up the issue of the account I was operating under to eliminate that as a contributing factor. Local admins groups on both computers are identical.

I think that permissions on the file/registry level have been mistakenly/inadvertantly reset on the problem machines. I simply seek to restore the correct settings with the least amount of hassle, since I'll have to repeat the process on all problem machines.

If you think I'm going down the wrong path here, please speak up...

 

[vulpine]

are all the 2000 machines at the same sp level? Do you have auto update going on ALL machines? some security patches mess with priviledges. If some are updating and some are not ....