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:

  1. 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)

  2. 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)

  3. 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.

  • Have you setup your management point in AD already? Looks like it's querying WINS, do you have a WINS server? – Chris S Oct 20 '10 at 13:24
  • We had the setup done by a consultancy firm, but it should be fully AD integrated with the AD scheme expanded. Is that what you mean? – HannesFostie Oct 20 '10 at 13:28
  • 1
    The schema extension and entries. If you open ADSI edit, default naming context, and look in DC=yourdomain, CN=System, CN=System Management; there should be an entry for your SMS Site, and CNs for your Site with the Site server. These entries should be automatically generated by the MP server if permissions were set correctly. Do you also have WINS in your environment? Is there more than one SCCM Server setup? – Chris S Oct 20 '10 at 13:44
  • These entries do in fact exist. There's a single server (which has been reinstalled with the same site code during the testing process, but I believe this happened correctly as we do not have any issues with our windows7 deployment (or so we believe, for now, anyway)). As far as WINS is concerned, we do not seem to have one in the domain for our classroom environment. – HannesFostie Oct 20 '10 at 13:57
  • From a failed XP machine, if you ping [MP_Server] does it correctly resolve the IP? How did you deploy the client, from the SCCM Console? – Chris S Oct 20 '10 at 14:17

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 /set on 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.

  • Hi. Haven't had time to check everything, will take care of going through it all tomorrow. Discover is set to AUTO indeed, but clicking discover on the client is unsuccessful. The site code is there though. Windows firewall is enabled, but I find it strange that some clients would get discovered while others don't, both with firewall on. It doesn't seem to be an issue on Win7 in any case. – HannesFostie Oct 21 '10 at 13:52
  • As far as time settings goes: it seems it doesn't sync time right away, but it does after a while. Again, this happens on all pc's. Here's the errors from eventlog, first is system and 2nd is application if I recall: pastebin.com/tjq5phef pastebin.com/Uhy61ry4 – HannesFostie Oct 21 '10 at 13:53
  • The discover site code button only works if you're logged in with a domain account that has local admin permissions, it won't work logged on as the local Administrator account, as that has no permission to query AD. Also from the logs you've posted the machines are having a lot of problems finding a domain controller, I think you need to look at that first, as if it can't find a domain controller then it won't be able to query AD to get the settings it needs. – GAThrawn Oct 21 '10 at 14:44
  • Thanks, I didn't know about logging in as domain admin. What could the problem with the DC be? I find it strange this only happens with some of the computers. I have no idea where to start looking... – HannesFostie Oct 22 '10 at 7:22

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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.