Machines Without SMS Client Installed

[ronifly]

We have a handful of clients at many of our secondary sites that do not have the Advanced client installed. What is the best way to "repair" or "RE-install" the client Remotely? I have tried to manually install the client from the SMS console only to get errors like the one below:

======>Begin Processing request: "SPUHUQVZ", machine name: "BlahBlah" SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:40 AM 4536 (0x11B8)
Getting a new request from queue "Incoming" after 100 millisecond delay. SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:40 AM 3212 (0x0C8C)
---> Trying each entry in the SMS Client Remote Installation account list SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:40 AM 4536 (0x11B8)
Waiting for change in directory "C:\SMS\inboxes\ccr.box" for queue "Incoming", (30 minute backup timeout). SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:40 AM 3212 (0x0C8C)
---> Warning: no remote client installation or SMS service account found SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:40 AM 4536 (0x11B8)
---> ERROR: Connected to BlahBlah registry, but couldn't connect to the \\BlahBlah\admin$ share using account '' SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:41 AM 4536 (0x11B8)
---> ERROR: Unable to access target machine for request: "SPUHUQVZ", machine name: "BlahBlah", error code: 1003 SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:41 AM 4536 (0x11B8)
STATMSG: ID=3014 SEV=W LEV=M SOURCE="SMS Server" COMP="SMS_CLIENT_CONFIG_MANAGER" SYS=STVSMS01 SITE=CS1 PID=1084 TID=4536 GMTDATE=Mon Aug 14 12:59:41.804 2006 ISTR0="BlahBlah" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:41 AM 4536 (0x11B8)
Retry request id for "SPUHUQVZ" set to "BlahBlah" SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:41 AM 4536 (0x11B8)
Stored request "BlahBlah", machine name "BlahBlah", in queue "Retry". SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:41 AM 4536 (0x11B8)
<======End request: "BlahBlah", machine name: "BlahBlah". SMS_CLIENT_CONFIG_MANAGER 8/14/2006 8:59:41 AM 4536 (0x11B8)


Any thoughts? I am fairly new to SMS and trying to get these clients cleaned up.
thank you
ron

 

[ncotton]

Have these machines got the firewall enabled?

Can you connect to \\clientmachine\admin$ from the site server?

It appears that you have not specified, or the AD account has changed for your SMS Installation Account.

check it ....
Site Settings > Client Installation Methods > Client Push Installation > Properties > Accounts > here should be a listed AD user that has been given Enterprise Admin permissions (added to Ent Admin group)

If there is one specified, try logging on to a machine using this account. It is possible that when creating this account, you may have made a booboo, and set password to expire, or something...thats a problem I had recently.

Check that and report back Ronnie

Hope this Helps.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[ronifly]

Good morning Neil,
I have checked all and all looks good and is a go. I am able to successfully connect to the clients admin$ from the site server, I have checked the account used for Client Installations, this account is set for password to never expire and has Enterprise Admin access. I have not tried to log into the system directly with this account, why is it that you would like for me to try this step?

Thank you
roni

 

[ncotton]

Well, at a conceptual level.
The SMS Installation Account is launching the client installation over the UNC using RunAs, which validates the Account and permissions in AD, logging on to a machine with this account, just to test will double check that the account is having no problems.

I had an access denied error turning up in some updates all of a sudden, it was because the Password had expired, 3 months after i set up the test domain, this was just a mistake on my part when creating the user, but there are many other issues that could have inadvertantly happened to the account...just try it and see.

Hope this Helps.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[ronifly]

Sure, makes perfect sense. All is good, I was able to log onto this system with this usesname.

 

[ncotton]

Is that account a member of the "Enterprise Admin" group in AD?

Hope this Helps.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[ronifly]

yes

 

[ncotton]

Is file and print sharing enabled? Firewall disabled? (or Firewall on with File and Print Sharing exceptions)

Hope this Helps.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[GerhardR]

maybe this helps?

Ok, I have it figured out - and in my opinion this is a huge 'bug' that
needs to be documented and/or addressed.

On our desktop images we set the LM compatibility level to '5', or
'Send NTLMv2 response only/refuse LM & NTLM'.

The default value for XP is '0' or 'Send LM & NTLM responses'.

I found MS article 842309 which explains that BITS 1.5 (which comes
with SMS 2003) 'allows logon credentials to be used for authentication
when the LmCompatibilityLevel is less than 2'.

However with BITS 2.0 (which comes with XP SP2) it's supposed to allow
authentication if the LmCompatibilityLevel is greater than or equal to
2.

This obviously is not happening, and as BITS 2.0 supports it, I would
contend that there is a bug with SMS 2003 SP2 and how it interacts with
BITS 2.0.

It would be ridiculous for a company running SMS 2003 in advanced
security to have to still enable their clients to use LM authentication
in order to get the advanced client pushed to them!!!

I changed the LM compatibility level to 1 and the advanced client
installed no problem.

(from:

http://groups.google.at/group/micro...ONFIG_MANAGER+&rnum=2&hl=de#cf359c7f08cf2bca)