Tuesday, February 26, 2013

Multicast error 0x80091007 during deployment

Today I want to configure multicast in ConfigMgr 2012 SP1. An important thing to do is enable multicast on the Distribution Point. Another important thing to do is enable multicast on the Operating System image. Just select "Allow the package to be transferred via multicast (WinPE only)" for that. Start a new deployment on a system and multicast should work immediately!?

After configure above settings an error message is displayed during deployment: 0x80091007. Looking in SMSTS.log the following is mentioned: The hash value is not correct. (Error: 80091007; Source: Windows). This can be solved with distribute the package on DP again. Unfortunately this isn't the case. I still get the same error message during deployment.
 
When disable multicast on the Distribution Point, deployment is working again. Is there someone who recognizes this error message and has a solution for it? I found THIS and THIS on MS TechNet, but no answer yet. Hope someone has a solution for me. Thanks!

Update 28-5-2013: Last month at customer location we created 3 images for multicast usage. First image (4GB) went fine immediately. Second image (6GB) went fine after update Distribution Point (DP), before that same error message. Third image (11GB) still isn't working, after multiple update DP actions. Still don't know why it's failing.. error messages are shown in the screenshot.

Update 19-6-2013: Nick send me a possible solution in comments. What you have to do is make sure you don't have a custom Multicast range set - use the setting "Use IPv4 addresses within any range" in the SCCM 2012 multicast tab under Distribution Point properties.

The default is 239.0.0.1 to 239.0.0.254 - if you have a custom range set - it IGNORES it and uses a random address in 239 range anyways. He has tried to statically set a 239 range on both SCCM multicast and WDS multicast settings - ignores them still uses a random address in the 239 range regardless.

On your Cisco core - if your using that - make sure your ACL's and Rendezvous Point ACL for PIM permits the 239 range. As soon as this was done it's all working. > Will try that myself next month!

41 comments:

  1. Were you able to find a solution to this mate?

    ReplyDelete
    Replies
    1. No yet actually. Didn't used it anymore at customers, but am doing this month an installation where multicast is needed. Stay tuned for more info later this month!

      Delete
    2. Hey Henk,

      Any update to this one? We did a sniff between for the client across routed vlans and see the WDS error 1406 which is essentially "time out" the SCCM 2012 sp1 error is still 0x80091007

      Delete
    3. Nope, at customer location we created 3 images for multicast usage. First image (4GB) went fine immediately. Second image (6GB) went fine after update DP, before that same error message. Third image (11GB) still isn't working, after multiple update DP actions. Still don't know why it's failing.. seems like a time out indeed.

      Delete
    4. Ok mate in my environment ive fixed it:

      Our install is also 2012 SP1. What you have to do is make sure you don't have a custom Multicast range set - use the setting "use any ipv4 range" in the SCCM 2012 multicast settings under distribution point settings.

      The default is 239.0.0.1 to 239.0.0.254 - if you have a custom range set - it IGNORES it and uses a random address in 239 range anyways. I have tried to statically set a range in the 239 on both SCCM multicast settings and on the WDS multicast settings - ignores them still uses a random address in the 239 range regardless.

      On your Cisco core - if your using that make sure your ACL's and Rendezvous Point ACL for PIM permits the 239 range. As soon as this was done its all working.

      Cheers,
      Nick

      Delete
    5. Well done and thanks for your solution. Will try it out myself within a few weeks and let you know the result. Very nice indeed!

      Delete
    6. I've also been told if your using hp switches they don't like the 239 range for multicast - maybe there is a fix for it but its a key point to make if you have procurve. We are a Cisco shop which is killer :))

      Delete
    7. Never seen this error on CM 2007 though, but maybe that was just luck..

      Delete
    8. I successfully solved the problem:

      #in Server Swith
      ip multicast-routing
      ip multicast auto-enable
      interface {VlanServer}
      ip address X.X.X.X 255.255.255.0
      ip pim sparse-dense-mode
      end

      #in Client Switch
      ip multicast-routing distributed
      ip igmp snooping querier
      interface {Vlanclient}
      ip address X.X.X.X 255.255.255.0
      ip pim sparse-dense-mode
      end

      thank for Nick Idea
      its all working.

      Delete
    9. im glad its working for you mate!

      regards
      Nick

      Delete
  2. Hello, i have the same problem with multicasts.If i disable multicast on SCCM DP the deployment is working.

    ReplyDelete
    Replies
    1. Hello, hope to have more information about this issue within 2 weeks from now.

      Delete
  3. I did a new multicast deployment today at a different customer, and it worked on first try. It must be installation-specific I think?

    ReplyDelete
    Replies
    1. On one image it's working, on the other above error message is shows. Strange thing! Hope to solve the error message today.

      Delete
    2. Did an update on the DP and it worked after that! No problems with multicast at this customer anymore.

      Delete
  4. At customer location we created 3 images for multicast usage. First image (4GB) went fine immediately. Second image (6GB) went fine after update DP, before that same error message. Third image (11GB) still isn't working, after multiple update DP actions. Still don't know why it's failing.. seems like a time out indeed.

    ReplyDelete
  5. Any progress on this problem? Exactly a same situation here... And HP switches and they will not work at all with default WDS settings.

    ReplyDelete
    Replies
    1. Just posted a new update on this issue. Hope it helps!

      Delete
  6. Hello, we've got the same issue, but no solve for it. Our WIM is 14GB. Update of DP didn't help. Range is set to automatic. Any Ideas?

    ReplyDelete
    Replies
    1. It has something to do with the size of the image and used Multicast ports. No solution known yet..

      Delete
  7. So, I figured out what the issue was using multicast vs using unicast in my environment. Multicast would fail every time if I was trying to PXE boot from a different VLAN on which the PSP exists.

    When I try to open a multicast session from VLAN 5 where my PSP is also located - then it works without error,(slow as hell though). I am using Meraki equipment, I will have to figure out what it will take to enable multicast across VLANs. (and why it is so slow even on the same VLAN)

    I hope this helps you, Henk

    ReplyDelete
    Replies
    1. Thanks Nick, for comment.
      Will try this myself also!

      Delete
    2. from looking at your SMSTS log that you posted, it seems that you are having the same issue I was.

      "Hash could not be matched for the downloded content. Original ContentHash = E568077A53B63FE644EDC46B1FB2E10017264E921E8D408347BE44FD449EA9E4, Downloaded ContentHash = "

      The above error indicating a hash mismatch when doing multicast is actually misleading. The problem is that the download never started. So, you get an empty file. The Multicast client still hashes the download folder, and compares it with the expected hash. And then it complains of a hash mismatch.

      So, the root of the problem is that when trying to open a Multicast session with the MCSP, the initial package (WIM files most of the time) do not download at all which is why it throws a hash mismatch error.

      I would be very curious to see what would happen if you uninstalled the multicast service point role in your distribution point (monitor mcsMSI.log and make sure to wait for it to finish uninstalling) by unchecking the multicast checkbox in the distribution point role properties - and then try to PXE boot.

      Delete
    3. Alright, well I guess you already stated that it is working when multicast is not enabled - this only brings us closer to the solution.

      Delete
    4. Thanks again Nick, you are right that unicast in this situation always is working. With multicast it depends on the size of the image if it is working. Next week I'm at the customer locatiuon again to try new config. Still curious how to solve this!

      Delete
  8. Seems I'm yet another in a long list of people seeing this issue. Unicast is working fine, multicast is a no-go with the exact same error, tried all of the above potential fixes but with no luck so far, image is 14GB.

    I'm watching my multicast routes(show ip mroute) when it supposably initiates the connection but the route never appears.

    ReplyDelete
    Replies
    1. Still no solution known to me. Multicast is failing with images 8-10GB and higher. Hope the issue is fixed when R2 is released later this year.

      Delete
  9. Yes I have the same issue. 17GB image. Disabled it for now. Please keep us updated.

    ReplyDelete
  10. I've got the fix!

    mount your boot image

    then add your server to the hosts file in mounted boot file

    only put server not server.domain.com

    then umount and redeploy boot image

    ReplyDelete
  11. We are also having the same problem. We have recently upgraded from our old Cisco core to a HP 5406zl. After the upgrade we were unable to image with system center using multicast. Were you having the same issue and just change the follow setting to the system image

    ReplyDelete
  12. Any update on this issue? Even after upgrading to R2 I still have this issue.

    ReplyDelete
    Replies
    1. Didn't see it for a while because I don't recommend multicast is most situations. In my experience this issue is only been seen with bigger (fat) images, not with a default Windows image. How big is your deployment image?

      Delete
  13. x86 is 5.82GB and x64 is 7.18GB

    ReplyDelete
    Replies
    1. Try to update Distribution Point before deployment. Otherwise still the same issue as mentioned in the blogpost.

      Delete
  14. As stated "The default is 239.0.0.1 to 239.0.0.254 - if you have a custom range set - it IGNORES it". With HP Procurve's you have to change this to something outside of these ranges:
    224-239.0.0.xx or 224-239.128.0.xx

    I chose 239.1.1.1 - 239.1.1.254, which is now working well.

    I fixed this error (0x80091007) in our SCCM 2012 SP1 deployment by editing the registry of the Distribution Points that provide cloning to match the custom range set within the SCCM configuration.

    The settings are found here:
    HKLM\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\McStartAddr
    and
    HKLM\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters\McEndAddr

    Change these to match your SCCM 2012 configuration and then restart the "Windows Deployment Services Server" service on the Distribution point. Success!

    ReplyDelete
    Replies
    1. Thanks for comment! Hope to try this in another implementation to try it out myself. To be continued.

      Delete
    2. Did you get to test this yet? Mark me up as another person with this issue. 2012 R2 with CU1 installed. Unicast works, multicast fails.

      I have a case open with MS to work through this.

      TS steps that will be taken in the next couple of days:

      1)Try multicast subnet local (since I am going across subnets).
      2)Try to increment the image version to regenerate the hash. (probably not the real issue here as noted in posts above).
      3)Have networking investigate some of these comments above and IPS'.

      Delete
    3. I should add that I don't have the custom IPv4 range set, just to use any (the default).

      Delete
  15. Running into this at a customer. Has anyone solved the issue? Thick images are being used so the sizes are quite large -20GB. I know that is not ideal but it is what we have right now.

    ReplyDelete
  16. Henk, have you noticed that multicasting with SCCM has very slow speeds? If so, have you been able to increase performance?

    ReplyDelete