MDT 2012 Multicast Failure
-
Tuesday, August 14, 2012 11:57 AM
I am experiencing issues with multicast transfers in MDT 2012, and for something that is essentially as simple as clicking a checkbox, I am baffled at what else could be going on to cause this.
We are running MDT 2012 on a 2008 R2 server, which is also the home of WDS. Now, multicasting straight from within WDS works fine, but for obvious reasons we need to have this functionality in MDT. The MDT Deployment Shares are established with custom images, setup files, driver support, applications, etc and all of the task sequences work flawlessly. When I enabled multicasting on the DS, I verified that the namespace was in fact created in WDS, however the session never gets created and no clients are able to join. During deployment, "Attempting multicast transfer" appears for a split second before falling back to unicast and completing the rest of the task sequence. Below is what I am seeing in both the BDD.log and LTIApply.log files:
------ Applying Windows image using Setup.exe ------ LTIApply 8/8/2012 2:10:56 PM 0 (0x0000)
Multicast transfer to directory: C:\MININT\Operating Systems\Win7x64_CI_8-7-12 LTIApply 8/8/2012 2:10:56 PM 0 (0x0000)
<Message containing password has been suppressed> LTIApply 8/8/2012 2:10:56 PM 0 (0x0000)
Command has been started (process ID 1412) LTIApply 8/8/2012 2:10:56 PM 0 (0x0000)
Console >
LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Console > Transfer Failed. [0x80070523]. LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Return code from command = -2147023581 LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Multicast transfer could not be completed, rc = -2147023581, falling back to using %DEPLOYROOT%\Operating Systems\Win7x64_CI_8-7-12\Win7x64_CI_8-7-12.wim LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
LTI applying image %DEPLOYROOT%\Operating Systems\Win7x64_CI_8-7-12\Win7x64_CI_8-7-12.wim using SETUP.EXE LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Unable to find SETUP, use imagex.exe as a backup. LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
------ Applying Windows image using ImageX.exe ------ LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
LTI applying image %DEPLOYROOT%\Operating Systems\Win7x64_CI_8-7-12\Win7x64_CI_8-7-12.wim using ImageX LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Property SourcePath is now = %DEPLOYROOT%\Operating Systems\Win7x64_CI_8-7-12 LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Multicast transfer to directory: C:\MININT\Operating Systems\Win7x64_CI_8-7-12 LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
<Message containing password has been suppressed> LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Command has been started (process ID 1468) LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Console >
LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Console > Transfer Failed. [0x80070523]. LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Return code from command = -2147023581 LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)
Multicast transfer could not be completed, rc = -2147023581, falling back to using %DEPLOYROOT%\Operating Systems\Win7x64_CI_8-7-12\Win7x64_CI_8-7-12.wim LTIApply 8/8/2012 2:10:57 PM 0 (0x0000)I've replaced the server name and share path with %DEPLOYROOT% in the log excerpt above, but in the actual log it has the correct path listed. This same error is being returned for each task sequence, on each Deployment Share. I have tried recreating a Deployment Share and enabling multicast transfer, but this yielded the same results, and I never see any clients in the WDS console.
What's strange is that we had this working when we temporarily tested it last year with MDT 2010, but we had decided not to implement it yet to due network restrictions. We are utilizing 802.1x port level authentication, however the systems are on forced auth ports and IGMP snooping is permitting on all devices between the clients and the MDT server. Like I said, multicasting works fine when deploying an image from WDS so this leads me to believe the issue is not network related.
I've searched countless hours on the issue, error codes, or similar symptoms and haven't found anything that solves my problem. We are gearing up for our large deployment of 1500+ systems and we really need to get this working. Any help is appreciated!!
- Edited by NexTech84 Tuesday, August 14, 2012 12:00 PM
All Replies
-
Thursday, August 16, 2012 12:21 PM
Have you tried this?
http://support.microsoft.com/kb/2582106
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
-
Thursday, August 16, 2012 12:33 PM
Hi Frank,
Thanks for the response! It seems that article relates to multicast failure in WDS. When I apply an image from directly within WDS it works fine, it seems to only be happening when I add the MDT LiteTouch boot image to WDS and run a task sequence. This pretty much eliminates a network issue causing the problem, however I have been working with our network engineer over the past week. He checked all the settings on switches/routers to ensure they were all configured properly for IGMP as well as fragmentation. We even reached out to the manufacturer for the network devices we are running, and they see nothing that would prevent what we are trying to accomplish.
-
Thursday, August 16, 2012 1:49 PMGotcha. I successfully avoided an 802.1x implementation at my workplace, but while we were looking into it I did read about its support for WinPE. Have you tried adding the feature in your boot disk. I believe you do it by going to the share properties and under the features tab you'll see the option. Sorry, I don't have much experience with 802.1x.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
-
Thursday, August 16, 2012 1:55 PM
Frank,
We haven't enabled 802.1x support yet, as we are waiting to get multicasting working first. The temporary solution for us when we need to mass image, is to change the ports on those machines to forced auth. In other words, we turn off 802.1x for systems we are imaging so the authentication is not an issue. The plan is to support 802.1x in the deployments, but right now we are in a crunch to just get the image out there, and unfortunately without multicasting this is going to take a long time with our 40GB image! I know I know it's huge, but trust me at this point in time it is needed.
-
Friday, August 24, 2012 5:45 PMDoes anyone have any ideas? We are still seeing the same behavior and I can't think of anything else to try. Coming up against our deadline here and this will help immensely if we can get it working...

