Let me start off by mentioning that I have no prior experience with SCCM, and that this is a proof of concept setup we are setting up in order to deploy our classroom environments more dynamically. The need arose to be able to change between OSes (XP and Win7, to begin with) and software (primarily Office 2003 and 2007 that are the problem children here).
We begun at the start, by deploying the OS without any additional software. The task sequence in question only has the App-V client. No other advertisements are enabled on the collection.
The Windows7 deployment seems to run without problems (so far). Sample size is not very big, but we have reason to believe so.
The WindowsXP deployment however does not perform as expected, with seemingly random computers not having their SCCM client or domain recognized in the SCCM console. It appears communication between the client and the server is "blocked" or does not occur (in the right manner).
The first symptom, next to the information (domain and client) not showing up in SCCM, is that there are only 2 Actions in the Configuration Manager Properties in the control panel on the client. After some looking around, I noticed the BITS service was not started, whereas it was on the clients that function properly. Starting it did not seem to resolve the problem automatically (we're about 1 hour after starting it manually).
I then looked up the logs on the client, and found several errors, the most relevant ones I believe are these:
CcmExec.log :
OutgoingMessage(Queue='mp_[http]mp_policymanager', ID={3250AB2B-F5B8-4227-9AC9-8884F17AD703}): Will be discarded (expired). CcmExec 10/20/2010 11:28:42 AM 548 (0x0224)
CForwarder_Base::Send failed (0x8000000a). CCMEXEC 10/20/2010 1:40:57 PM 356 (0x0164)
ClientIDManagerStartup.log :
RegTask: Failed to send registration request message. Error: 0x8000000a ClientIDManagerStartup 10/20/2010 2:44:57 PM 356 (0x0164)
RegTask: Failed to send registration request. Error: 0x8000000a ClientIDManagerStartup 10/20/2010 2:44:57 PM 356 (0x0164)
LocationServices.log :
Failed to resolve 'SMS_SLP' to IP address from WINS LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
LSGetSLP : Failed to resolve SLP from WINS, is it published LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
LSGetManagementPointForSiteFromSLP : Unable to get the list of SLPs LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
Failed to retrieve Default Management Point from SLP LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
Failed to resolve 'NLB_001' to IP address from WINS LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
Failed to resolve 'MP_001' to IP address from WINS LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
Failed to retrieve default MP through WINS. LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
Failed to reset certificate request times. (0x80041002) LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
Failed to update security settings over AD with error 0x80004005.
LocationServices 10/20/2010 11:34:56 AM 356 (0x0164)
Update: Extra information
The setup is done on a single physical server running SCCM, SQL Server 2008 and App-V. It is fully AD-integrated and the AD scheme is extended. Rights should not be an issue as most of the pc's deploy fine, there's just always a couple that don't. Someone asked if there was a WINS server; there's not. I'm not sure if this is a problem, wouldn't expect it to be... The "faulty" computer can ping and resolve the hostname of the SCCM server just fine.
Any help would be appreciated, we're kind of stuck atm.
I hope I provided enough information.
Answer
Seeing as the BITS service was never started on the failed computers, I decided to try a workaround where I manually start the service before deploying the SCCM client. However, I kept getting errors where some commandline tools did not seem to work, or I couldn't start the service in the current environment, being WinPE. I tried several types of scripts, both with net start and sc start. None worked...
So I attempted a more simple aproach: setting the service to automatic via GPO. I expected this to work since apparently the client was being installed under WinPE, which required a reboot into WinXP before the client and SCCM itself "connect". Seems I was right, the service starts correctly, and so far all of our clients were discovered. So far so good...
No comments:
Post a Comment