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.
Are the machines picking up your SCCM Site Code automatically? Presumably you're deploying the SCCM client with the SMS Site Code set to AUTO, which would normally mean that through a combination of AD and/or DNS the machines should find your SCCM site code and server automatically.
On a problem PC, if you look in Control Panel, Configuration Manager applet, Advanced tab you should see "Currently Assigned to Site Code:" with your three letter site code in the box. If it's not there, click the Discover button and make sure it appears.
The errors you're getting look like the clients tried all the methods it knows for discovering the management point and ended up looking for the SLP in WINS, as it couldn't find the management point in DNS, and couldn't access the schema extensions in AD. See Configuration Manager and Service Location (Site Information and Management Points), see also How to Extend the Active Directory Schema for Configuration Manager. Check the permissions on the System Management container that's been created, most methods of extending the schema don't automatically assign the needed permissions to this folder
Other things worth checking are time related settings on the client, make sure that the client are set to the right time (also check what time zone they think they're in to make sure the clock is really showing the right time), if the clock on your clients is more than an hour out from the server you'll have problems. Do a
net time /seton the client to sync it up with your domain controller.Also check the firewall settings on the XP machines, we've had problems with them where SCCM isn't getting through the built-in XP Windows Firewall properly.
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...