Hello We are doing a Windows XP SP2 OSD deployment to different hardware platforms with SCCM 2007 R2. We are using multicast and it is working really well for us but there has been 2 occassions where multicast just seems to stop in the middle of downloading the wim or doesnt start. Here is the scenario: 1. 1 Lenovo that has already open a multicast session to download our OS wim image 2. 3 additional PC(different model) joins and tries to download the wim (opening multicast session \\serversite\ ...) but never gets pass this. When this happens the Lenovo suddenly stops downloading the wim and gets stuck at 20% and the other machines are still trying to open a multicast session. This would go on for an 1-3 hours but does not error out. We are able to get the multicast session working again by ending the Task Sequence for all 4 machines. We restart the Task Sequence for the 3 PCs at #2 above and they are now able to open a multicast session. Note, we did not start the TS for the Lenovo machine. Has anyone seen this scenario before where a machine would just suddenly halts the multicast session?

do you see any errors in MCSISAPI.log file ?my SCCM step by step Guides > http://www.windows-noob.com/forums/index.php?showtopic=1064

where can I find the MCSISAPI.log? I looked for it on the primary CM server logs(\\server\sms_COR\logs) and looked on my DP server logs and cannot find it. Thanks

Binhn, Did you find a solution to this problem? I am having the same issue. Thanks

McsISAPI.log Provides information about the multicast service point Configuration Manager 2007 client request responses. Log file location: <ConfigMgrInstallationPath>\SMS_CCM\Logs does that log file tell you anything ? My step by step SCCM Guides I'm on Twitter > ncbrady

Not really. My doesn't show any error and doesn't tell me much. It keeps repeating: <![LOG[========== BEGIN: IsapiThread ==========]LOG]!><time="08:34:28.567+300" date="10-12-2010" component="smsmcs" context="" type="0" thread="5452" file="mcsisapi.cpp:889"> <![LOG[Query string to parse: 'op=healthcheck'.]LOG]!><time="08:34:28.569+300" date="10-12-2010" component="smsmcs" context="" type="1" thread="5452" file="httphandler.cpp:394"> <![LOG[========== END: IsapiThread ==========]LOG]!><time="08:34:28.661+300" date="10-12-2010" component="smsmcs" context="" type="0" thread="5452" file="mcsisapi.cpp:1030"> <![LOG[========== BEGIN: HttpExtensionProc ==========]LOG]!><time="08:39:28.565+300" date="10-12-2010" component="smsmcs" context="" type="0" thread="2960" file="mcsisapi.cpp:1116"> <![LOG[========== END: HttpExtensionProc ==========]LOG]!><time="08:39:28.566+300" date="10-12-2010" component="smsmcs" context="" type="0" thread="2960" file="mcsisapi.cpp:1224"> <![LOG[========== BEGIN: IsapiThread ==========]LOG]!><time="08:39:28.566+300" date="10-12-2010" component="smsmcs" context="" type="0" thread="5452" file="mcsisapi.cpp:889"> <![LOG[Query string to parse: 'op=healthcheck'.]LOG]!><time="08:39:28.566+300" date="10-12-2010" component="smsmcs" context="" type="1" thread="5452" file="httphandler.cpp:394"> <![LOG[========== END: IsapiThread ==========]LOG]!><time="08:39:28.640+300" date="10-12-2010" component="smsmcs" context="" type="0" thread="5452" file="mcsisapi.cpp:1030"> Thanks in advance Niall!

I'm experiencing this same issue, has anyone found a solution?!?

For what it's worth: I ran into a similar issue. OSD task sequence was targeted to a set of machines, 5 - 7 machines would attach to the MCS and start streaming the WIM. Any later machines would be recognized by the WDS service but not download the image. Restart the WDS service and all machines that were waiting will start downloading. After investigating, I discovered that two other packages were advertised to the DP on the server hosting the MCS packages. Once I removed all packages (leaving the MCS enabled package) everything is working fine. Best guess is that WDS does not play well with the SCCM DP. My theory is that the MCS starts streaming to a couple machines, then another machine requests a package from the DP which causes WDS to go into a wierd state. Bob.