Multicast Fails - Authentication error?

Problem: multicast of an image file fails with a hash mismatch error every time. However, it appears to mismatch because it fails to open the multicast session properly and thus doesn't download a file at all. The error (0x6ba) seems to indicate "RPC Unavailable" according to various forums, but I've been trying to troubleshoot that for weeks with no success.

<![LOG[Download: Server=SCCM01 Namespace=http://SCCM01.school.edu/SMS_DP_SMSPKG$/UCF00014 RemoteObject=http://SCCM01.school.edu/SMS_DP_SMSPKG$/UCF00014  LocalObject=C:\_SMSTaskSequence\Packages\UCF00014.{C2EC9C25-B5DF-4B32-A72B-8F6FF8DC174D}]LOG]!><![LOG[Token before WdsTransportClientStartSession]LOG]!><![LOG[Token is for User: NT AUTHORITY\SYSTEM]LOG]!><![LOG[ThreadId: 0x7e8  User: NT AUTHORITY\SYSTEM]LOG]!><![LOG[[Callback:SessionComplete:0x6ba]]LOG]!><![LOG[WdsTransportClientStartSession(m_hDownload), HRESULT=800706ba (e:\nts_sccm_release\sms\server\mcs\consumer\mcdownload.cpp,182)]LOG]!><![LOG[pDownload->Download(pwszServer, pwszNamespace, pwszRemoteObject, pwszLocalObject, uCacheSize), HRESULT=800706ba (e:\nts_sccm_release\sms\server\mcs\consumer\mcclient.cpp,120)]LOG]!><![LOG[Encountered error transfering file (0x800706BA).]LOG]!<![LOG[Sending status message: SMS_OSDeployment_PackageDownloadMulticastStatusFail]LOG]!><![LOG[Setting authenticator.]LOG]!><<![LOG[Set authenticator in transport]LOG]!><![LOG[Sending StatusMessage]LOG]!><![LOG[Setting message signatures.]LOG]!><![LOG[Setting the authenticator.]LOG]!><<![LOG[CLibSMSMessageWinHttpTransport::Send: URL: SCCM01.school.EDU:80  CCM_POST /ccm_system/request]LOG]!><![LOG[Request was successful.]LOG]!><![LOG[Download done setting progress bar to 100]LOG]!><![LOG[VerifyContentHash: Hash algorithm is 32780]LOG]!><![LOG[Hash could not be matched for the downloded content. Original ContentHash = 380B8E309C1C1C34CB65B2725AC364D6CFBE04B560D792EAA68257C8CB4CDB4A, Downloaded ContentHash = ]LOG]!><![LOG[0L == TS::Utility::VerifyPackageHash (pszContentID, sDestination), HRESULT=80091007 (e:\nts_sccm_release\sms\framework\tscore\resolvesource.cpp,3256)]LOG]!><![LOG[DownloadContentAndVerifyHash() failed. 80091007.]LOG]!>

Troubleshooting so far:

1. Verified multicasting set up properly on network (been using SCCM for a few years now, always worked before).
2. Set IIS to use Anonymous connections on the SMS_DP_SMSPKG$ share, and set the DP to allow Anonymous connections from the ConfigMgr application.  That didn't work, so I then set IIS to use Windows Authentication and unchecked Anonymous on the DP settings.  Still no dice.
3. I've mucked about with the content itself for three weeks, changing multicast settings on the DP and the image file, updating, redistributing, verifying, removing, and distributing newly uploaded image files again.  No change, same error message on the client's SMSTS.log.
4. IIS server log shows the client connecting, with HTTP code 200 (successful connection).  DP is set to use HTTP or HTTPS.
5. Tried setting DP to use Network Access Account to access the site database instead of the local machine account, still no change.  (This is a single, stand alone site with the DP, MP, and other roles installed on it.)
6. Per some older forum posts, I verified that the SCCM server is not broadcasting on IPv6, and that the NIC driver is not the old E-series, but the newer V-series instead.  The server is a VM in our datacenter.
7. Verified our DNS records for the SCCM server are correct.  Even re-created them for good measure; no change.

Notice that the log file shows a successful connection to the server - I can ping it from the F8 command window just fine.  I can distribute the client and SCEP without issue, and it finds the task sequence for the client machine without any problems.  The failure only occurs when the client tries to open a multicast session with the server, but all the logs I've read through indicate no obvious faults.  I'm at my wits end here, and would appreciate any advice.

P.S. This all happened in November after the server was updated with a new CU.  Somehow it botched things and the technician had to re-install parts of the SCCM console; I'm not exactly sure what components were effected.