locked
SCCM 2012 -- Configuration Manager Client Upgrade Package -- Distribution Errors RRS feed

  • Question

  • I cannot get my Configuration Manager Client Upgrade Package (XXX00003) to distribute successfully. Currently every time I run the powershell script to Refresh my DPs it fails. The log errors and fix suggestions are standard 0x8007003 fair. I am not going to post of ton of logs in this first post because I believe I know what is going on. All my other distributions are working fine and my servers are all 2008 R2. My behavior is exactly like the following threads:

    http://social.technet.microsoft.com/Forums/en-US/configmanagerdeployment/thread/d98ca330-7426-4485-8f43-6c1eb0020eed/

    http://social.technet.microsoft.com/Forums/en-US/configmanagerdeployment/thread/ee8bafa8-b98b-4428-8e2a-3e200d06ca3e

    http://social.technet.microsoft.com/Forums/en-us/configmanagermigration/thread/11df0f63-d146-434d-91f3-c4e826fee92c?/

    The 3rd post was suggested in the first two threads as a way to fix this issue. Third post contains the standard WMI script to grab the list of DPs and set RefreshNow = True but as discussed by people in each of these threads this is not working for me. I truly believe that I am having the common issue that has been prevalent since the beginning of time with SCCM and SMS -- the first distribution of that package has something nebulous wrong causing the distributions to fail. --EDIT (Thinking more on this the problem I am referring to actually manifests itself on client download not source distribution -- that doesn't change what I want to try below and can't.)

    In looking in the DB at the dbo.SMSPackages view I can see that the source location is correct but I can also see that the StoredPkgVersion is set to 1. I think in order to ever get this to work I need to do an "Update Distribution points with a new source version" which will increment this number and cause SCCM to totally re-evaluate the source for this package. The script provided in these solutions does not cause a true update that increments the source version number. The script simply tries to refresh the DPs.

    With the package missing from the console and the SMS_Package WMI class I don't see how I can possibly force a source version update on this package. Is there a way that anyone knows?

    I am very much not a fan of hidden items like this that can cause errors in my logs. It just makes fixing them that much more of a pain. I suppose the forums aren't really the place to make the suggestion that this should be updated to show to users...I may have to find the proper route to do that. :)

    With all that said I can post logs if you want to see them, but trust me they mirror the logs in the previos posts very closely. Thanks in advance!


    • Edited by kwood_MN Monday, December 3, 2012 8:42 PM
    Monday, December 3, 2012 8:41 PM

Answers

  • We might get odd results from messing around with the built-in client package. Also the built-in package is different as part of their built-in-ness, won't look the same as real packages.

    There are others on these forums reporting similar issues when adding the built-in client package to new Distribution Points, some can resolve this with PowerShell ...  I haven't come across your issue, if I had, I'd of spun up a CM test lab to reproduce it (few DP's, site server) using CM12 SP1 Beta, if not then I'd log it as a bug on Connect.


    Rob Marshall | UK | My Blog | WMUG

    Wednesday, December 12, 2012 12:37 AM

All replies

  • Your own custom package ... do you distribute it to your DP's before your try to Refresh it?

    Have you tried using the PowerShell applets in SP1 Beta


    Rob Marshall | UK | My Blog | <a href="http://www.wmug.co.uk>WMUG

    Sunday, December 9, 2012 1:10 PM
  • Thanks for your reply Rob.

    Do you mean this is my own custom package or are you asking if when I create packages do I distribute to my DPs before I try to refresh? This package I am talking about it is the hidden built in Client Upgrade package and when I do make a custom package of course I distribute packages to my DPs before I try to refresh them.

    As of right now I know very little of the Powershell applets in SP1 Beta, I will check them out thanks.

    Monday, December 10, 2012 12:42 PM
  • We might get odd results from messing around with the built-in client package. Also the built-in package is different as part of their built-in-ness, won't look the same as real packages.

    There are others on these forums reporting similar issues when adding the built-in client package to new Distribution Points, some can resolve this with PowerShell ...  I haven't come across your issue, if I had, I'd of spun up a CM test lab to reproduce it (few DP's, site server) using CM12 SP1 Beta, if not then I'd log it as a bug on Connect.


    Rob Marshall | UK | My Blog | WMUG

    Wednesday, December 12, 2012 12:37 AM
  • I'm just curious if any resolution was found for this. I am experiencing the same issues. I have tried the Powershell scripts to no avail as well.

    Wednesday, January 2, 2013 6:04 PM
  • I too am seeing this issue.  Identical.

    The environment I'm seeing this in is a single-site SCCSM 2012 configuration with (currently) one remote DP.  The Configuration Manager Client Upgrade package (XXX00003) distribution to the local DP is successful, but the remote DP fails.  I too have followed the troubleshooting advice and steps in the links kwood_MN lists above, with similar disappointing results.

    I wonder if this is caused by an action I took on my remote DP.  I had initially deployed the DP and set up PXE on it.  PXE was not functioning correctly (probably because I fiddled with WDS directly... oops), and I pulled the DP off that server.  After making sure that all SCCM components were removed from the server, I re-deployed the DP (with PXE) to that server.  Since then the XXX00003 package has not been able to successfully be distributed to this DP.

    I too believe that being able to force a package "Update" rather than a "Refresh" might solve the problem, but haven't found a way to do this yet.

    I have not updated the site to SP1 yet, and would like to resolve this only issue before doing so.

    Wednesday, February 6, 2013 2:49 PM