locked
Using Distribution Point Sharing generated Hash Errors RRS feed

  • Question

  • When I enabled distribution point sharing on my source hierarchy,  my migrated OSD Packages were generation lots of random hash error failures.  The content had also been distributed to the new distribution point but for some reason in the logs it was still attempting to access from the shared distribution point.  After disabling shared distribution points the hash errors went away.  Anyone know what would cause this?  Is there a way to control if a system uses a shared distribution point or a new cm12 distribution point?
    Friday, May 10, 2013 5:04 PM

Answers

All replies

  • If I recall correctly, you cannot have a system provisioned as a shared distribution point AND a CM12 site server distribution point - the site system role installer does not permit it.  In what order did you set these options?  Did you install a CM12 site system role onto the remote CM07 system first and then initiate the migration process and shared DP? 

    My Personal Blog: http://madluka.wordpress.com

    Sunday, May 12, 2013 8:12 PM
  • The shared distribution point does hot have a CM12 distribution configured on it.  It is still a CM07 distribution point.  I configured a Source Hierarchy to use my CM07 primary site and enabled distribution point sharing.  I migrated some packages and task sequences, and then distributed the content to new cm12 distribution points.  No changes were made to the CM07 environment.  When I was deploying the task sequence with CM12 I received failures that specified hash errors.  The logs showed that the task sequence was attempting to use the shared distribution as a source.  When I went into the Source Hierarchy settings on cm12 and disabled the shared distribution points, the Task sequence completed with no errors.
    Monday, May 13, 2013 3:58 PM
  • Do you have Antivirus/Malware protection running on those DPs?

    Nicolai

    Thursday, May 16, 2013 8:30 AM
  • Yes there is AV installed on the Dp's.  The SCCM shares are included in the av exemptions so they will not be scanned.  My hunch is that when content is deployed to a distribution point on the destination hierarchy, it gets a new or different hash but for some reason the deployment still tries to use the shared distribution point on the source hierarchy.  Removing the shared distribution points forces the deployment to use the new distribution points.
    Thursday, May 16, 2013 3:07 PM
  • On one of the affected packages, first choose to "Update Distribution Points" for that object in CM07 and once that has settled, perform a migration into CM12 of changed objects and try again.

    My Personal Blog: http://madluka.wordpress.com

    Thursday, May 16, 2013 7:46 PM
  • I have the same issue -- Task sequences that apply OS images fail with hash errors when using shared distribution points from SCCM 2007.

    I checked the TS logs and found that hash query returns a blank value when connecting with http to an SCCM 2007 distribution point. This doesn't seem like something that would improve by updating distribution points in SCCM 2007 as the hash values contained in SCCM 2007 are fine.

    The way I worked around this was simply to turn off sharing of distribution points. In theory, I could add a task sequence step that modifies the hosts file being used so that CM 2007 distribution points resolve to a dummy address, but this seems like too much trouble.

    Another step in troubleshooting  is verifying the network access account and its ability to access distribution points. I reworked this setup, but it didn't seem to have an effect.

    So, this issue still hasn't been addressed in a satisfactory manner.

    Thursday, May 30, 2013 1:51 PM
  • I turned off sharing for the time being as well.  The only problem is that in order to upgrade a distribution point sharing needs to be turned on so while we are upgrading them towards the end of our migration some of our migrated task sequences will be inaccessible for a short time.
    Thursday, May 30, 2013 2:33 PM