This comes up in System Center Configuration Manager

0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

1
I recently enabled the FSP role on my MP and I'm seeing several similar warnings in the status message viewer:
asd
SMS_MP_FILE_DISPATCH_MANAGER 5401 MP File Dispatch Manager cannot copy files from "<DRIVE>:\SMS\MP\OUTBOXES\ddr.box" to "\\SITESERVER.F.Q.D.N\SMS_AP2\inboxes\auth\ddm.box".
Possible cause: The destination drive is full.
Solution: Make more space available on that drive.

Possible cause: The destination site system is turned off, not connected to the network, or not functioning properly.
Solution: Verify that the site system is turned on, connected to the network, and functioning properly.

Possible cause: MP File Dispatch Manager does not have sufficient access rights to remotely administer the site system.
Solution: Verify that the Site System Installation accounts are properly configured to allow the site to remotely administer the site system.

Possible cause: Network problems are preventing MP File Dispatch Manager from properly accessing the site system.
Solution: Investigate and correct any problems with you
For whatever reason, I'm seeing this for a handful of outboxes/inboxes.  I created a group in AD that contains my site server and MP's and added that group to the local administrators group of all my DP's.  However, I'm suspicious this isn't working.  I was seeing other access denied errors in various logs that generally indicate the installation account doesn't have sufficient rights.  I've explicitly added those servers to the local admin group and things are working much better.

Things you might want to consider:
  1. If you haven't explored the possible causes & possible solutions, try that first before growing your troubleshooting scope.  Too many changes too fast won't necessarily help you understand how you fixed it.  Also keep record of what changes you made so you can undo if necessary.
  2. Make sure those folders exist!  Some posts online have reported that the directories were just missing.  Highly unusual IMHO.  Recreate them and make sure it inherits permissions. (or compare another directory that is working and apply the same permissions to your newly created directory.)
  3. Check are the share & NTFS permissions and re-apply them if necessary

Report back your findings so we can all learn!
Answered 07/03/2014 by: haxin
Orange Senior Belt

Please log in to comment

Answers

-1

OK, looks like you try to get SCCM te write to a location where it doesn't have priviliges.

The account running the SCCM actions doesn't have rights everywhere in your domain. Even though its surely local-admin equivalent on workstations, once you leave the boundries of that system and move to access on UNC-paths you have a problem.

Seems you want to write something into a users inbox. Best way to do that is let the user take care of that.

Create a User-run-once task from your package for each user that uses the software (active setup). This task should write the users files from a temporaray local location you create to the users own mailbox location. Since it nruns in the context of that users session the privileges will be OK. The run-once task will be executed the next time the user logs on. You might have to trigger a reboot with the first-run for each user if the placement of the files is critical to the applications functionality. 

 

 

Answered 12/17/2013 by: EVEEN
Green Belt

Please log in to comment
Answer this question or Comment on this question for clarity