SCCM 2012 DP Errors: SendFiles Failed

One of my distribution points recently stopped getting DP updates.  I tried my normal troubleshooting steps - creating a new package, checking disk space, source folder permissions, server reboot, etc., but no dice.  I reviewed the DISTMGR.LOG on the primary site responsible for the distribution point, and found the following:

UpdatePackageData: Failed to get class of SMS_PackagesInContLib. Error code: 0x80041002 SMS_DISTRIBUTION_MANAGER 5/12/2015 6:46:04 PM 20164 (0x4EC4) Failed to update package share data into WMI on the distribution point SMS_DISTRIBUTION_MANAGER 5/12/2015 6:46:05 PM 20164 (0x4EC4)

When I look in the PKGXFERMGR.LOG, I found the following:

ExecStaticMethod failed (80041013) SMS_DistributionPoint, AddFile SMS_PACKAGE_TRANSFER_MANAGER 5/12/2015 9:38:04 PM 16912 (0x4210) CSendFileAction::AddFile failed; 0x80041013 SMS_PACKAGE_TRANSFER_MANAGER 5/12/2015 9:38:04 PM 16912 (0x4210) ExecStaticMethod failed (80041013) SMS_DistributionPoint, AddFile SMS_PACKAGE_TRANSFER_MANAGER 5/12/2015 9:38:04 PM 412 (0x019C) CSendFileAction::AddFile failed; 0x80041013 SMS_PACKAGE_TRANSFER_MANAGER 5/12/2015 9:38:04 PM 412 (0x019C) CSendFileAction::SendFiles failed; 0x80041013 SMS_PACKAGE_TRANSFER_MANAGER 5/12/2015 9:38:05 PM 16912 (0x4210) CSendFileAction::SendFiles failed; 0x80041013 SMS_PACKAGE_TRANSFER_MANAGER 5/12/2015 9:38:05 PM 16912 (0x4210) Sending failed. Failure count = 18, Restart time = 5/12/2015 10:08:05 PM Romance Daylight Time SMS_PACKAGE_TRANSFER_MANAGER 5/12/2015 9:38:05 PM 16912 (0x4210)

I searched around and found no help anywhere.  A few people ran into the issue, but the threads never went as far as to find resolution.   From plenty of troubleshooting in the past, and some hints in the errors, it was obvious that 0x80041002 and 0x80041013 were WMI failures.  I backed up the repository (c:\windows\system32\wbem\repository), and then I reregistered all DLLs in c:\windows\system32\wbem, mofcomp'd all the MOFs in the WBEM folder, and then MOFCOMP'd all the MFLs through the WBEM subfolders.  Same issue.  Next, I reinstalled PULLDP.MSI, hoping that it contained whatever WMI classes or MOF information that was required, but that didn't work either.  Another server reboot for good measure, and I was still in the same spot.

My last step was to run WMIDIAG 2.2 from Microsoft.  It revealed that ROOT/SCCMDP, SMSDPProvider was being referenced but that the DCOM registration was missing.  A little searching and I found that SCCMDP is built from smsdpprov.mof.  So, I found that MOF in the SMS_DP$ share, under \sms\bin.  I MOFCOMP'd that, and then I also reregistered all the DLLs in that folder with REGSVR32.  Normally I would have done the MOF first, tested again, and then each DLL at once, but I'd been troubleshooting for a few hours at this point and really just wanted the issue resolved.

Once I took care of the MOF and registered the DLLs, the issue was resolved and my content started replicating again.

Edit October 6, 2015: In response to a comment below, here is how to register a DLL, multiple DLLs, and MOFs:

To register a Single DLL, open an elevated command prompt, and run regsvr32 as shown below.  You will get a pop-up on the success or failure of the registration.  Not all DLLs can be registered, some failures are normal.  RegSvr32 supports a /s switch if you would like to suppress the notification.

To register an enter folder of DLLs, run for %F in (*.dll) do regsvr32 /s %F within the elevated folder.  The FOR command will loop over all the DLLs and register them.  You can remove the /s, but you'll get a lot of pop-ups.  Make sure to run this from the folder that has the DLLs within it.  If you are automating this within a batch file, you'll need to use a double percent sign (e.g. %%F).

And finally, to compile a MOF, you can use MOFCOMP.EXE.  There is a -check switch you can use to see if it'll compile before you actually compile it.  The command is simple, just MOFCOMP followed by the MOF name, as shown in the example below.