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!
Were you able to find a solution to this mate?
ReplyDeleteNo 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!
DeleteHey Henk,
DeleteAny 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
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.
DeleteOk mate in my environment ive fixed it:
DeleteOur 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
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!
DeleteI'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 :))
DeleteNever seen this error on CM 2007 though, but maybe that was just luck..
DeleteI successfully solved the problem：
Delete#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.
im glad its working for you mate!
Deleteregards
Nick
Hello, i have the same problem with multicasts.If i disable multicast on SCCM DP the deployment is working.
ReplyDeleteHello, hope to have more information about this issue within 2 weeks from now.
DeleteI hope too !
DeleteI did a new multicast deployment today at a different customer, and it worked on first try. It must be installation-specific I think?
ReplyDeleteOn one image it's working, on the other above error message is shows. Strange thing! Hope to solve the error message today.
DeleteDid an update on the DP and it worked after that! No problems with multicast at this customer anymore.
DeleteAt 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.
ReplyDeleteAny progress on this problem? Exactly a same situation here... And HP switches and they will not work at all with default WDS settings.
ReplyDeleteJust posted a new update on this issue. Hope it helps!
DeleteHello, 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?
ReplyDeleteIt has something to do with the size of the image and used Multicast ports. No solution known yet..
DeleteSo, 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.
ReplyDeleteWhen 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
Thanks Nick, for comment.
DeleteWill try this myself also!
from looking at your SMSTS log that you posted, it seems that you are having the same issue I was.
Delete"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.
Alright, well I guess you already stated that it is working when multicast is not enabled - this only brings us closer to the solution.
DeleteThanks 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!
DeleteSeems 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.
ReplyDeleteI'm watching my multicast routes(show ip mroute) when it supposably initiates the connection but the route never appears.
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.
DeleteYes I have the same issue. 17GB image. Disabled it for now. Please keep us updated.
ReplyDeleteI've got the fix!
ReplyDeletemount 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
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
ReplyDeleteAny update on this issue? Even after upgrading to R2 I still have this issue.
ReplyDeleteDidn'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?
Deletex86 is 5.82GB and x64 is 7.18GB
ReplyDeleteTry to update Distribution Point before deployment. Otherwise still the same issue as mentioned in the blogpost.
DeleteAs 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:
ReplyDelete224-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!
Thanks for comment! Hope to try this in another implementation to try it out myself. To be continued.
DeleteDid you get to test this yet? Mark me up as another person with this issue. 2012 R2 with CU1 installed. Unicast works, multicast fails.
DeleteI 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'.
I should add that I don't have the custom IPv4 range set, just to use any (the default).
DeleteRunning 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.
ReplyDeleteHenk, have you noticed that multicasting with SCCM has very slow speeds? If so, have you been able to increase performance?
ReplyDeleteAnyone find a solution for this? Still getting 0x80091007 when multicasting.
ReplyDelete