Site server does not have sufficent rights to the source directory - SCCM 2019

Matthew Sadler 1 Reputation point


Looking for some help. We have just needed to build a new DP in Australia as cockroaches decided that the old physical server was a nice place to live (no I am not joking) however, we are trying to distribute the content to the DP and keep getting met with this error. I have tried rebooting the DP, restarting the SMS_Executive service on the primary server but still no luck.

I have also checked the Administrators group on the DP and I can see the primary site server is in there aswell as all of our SCCM service accounts.

Looking for any help I can get. I am fairly new to SCCM and only know the basics.

Thanks in advance.

Not Monitored
Not Monitored
Tag not monitored by Microsoft.
27,085 questions
0 comments No comments
{count} votes

5 answers

Sort by: Most helpful
  1. Jason Sandys 30,936 Reputation points Microsoft Employee

    A few comments/questions:

    • There is no such thing as SCCM 2019. Can you please clarify what version of Configuration Manager (ConfigMgr) you are using?
    • There are no service accounts in ConfigMgr.
    • Is the primary site server's account directly added as a local administrator on the new site system?
    • Did you give the new site system a new name or is it reusing a name?
    • Is the new site system in the same domain and forest as the primary site server?
    • Where exactly are you seeing the message you noted in your title? If a log files, please indicate which log file and post a complete, and relevant portion from that log file as single lines from a log file are more or less useless for troubleshooting.
    • The error message you called out in the title is unrelated to any DP as DPs do not access source locations -- as noted though, without more context about this error message, not much more can be said.

  2. Jason Sandys 30,936 Reputation points Microsoft Employee

    Slightly embarrassed. I am still very new to SCCM.

    No need, everyone is new at some point to all kinds of things.

    First tip: It's not SCCM (for a variety of reasons). Many/some folks still refer to it as such, but it's really not and really never was. That's a whole side, semantic, ideological discussion/argument though that's more or less irrelevant.

    The first log shows an error code of 53 when attempting to connect. Assuming the FQDN noted (since I can't see what it is and it wouldn't mean anything to me anyway) is for the "new" site system, that's the root cause here.

    Error code 53 means "The network path was not found." This literally means the system is not accessible on the network (from the primary site server in this case) and is typically indicative of a name resolution (DNS) issue but could also be a firewall issue or the system simply not being online or powered off. There's no definitive way to know which it is without troubleshooting and possible direct examination of the system itself.

    One question you missed answering was whether or not you used a new name for the new site system?

  3. Jason Sandys 30,936 Reputation points Microsoft Employee

    dcdiag doesn't test name resolution from a client, that just tests whether the DNS server itself is healthy.

    The log above shows a different issue although this appears to be network related as well.

    I am able to serf to the server via File Explorer

    From the primary site server or your client workstation? If your workstation, then that's not a sufficient test since that's a different network path to the new site system. Also, it's not using the same credentials so wouldn't eliminate a possible authentication issue.

    To best manually recreate and thus test what's going on in the log above, you need to connect, from the primary site server to the new system using a WMI tool (like WBEMTest) to the namespace noted in the log using the local System account of the primary site server.

    0 comments No comments

  4. Matthew Sadler 1 Reputation point

    Hi Jason,

    I was able to serf from the primary site to the DP. I used the tool as you requested and all connected perfectly with no errors.


    Anything else I can try?


    0 comments No comments

  5. Jason Sandys 30,936 Reputation points Microsoft Employee

    I used the tool as you requested and all connected perfectly with no errors.

    You did this using the local System account on the primary site server?

    If so, this rules out policy or authentication issues leaving network related issues as the primary suspect. You'll have to coordinate with the network team as this is specific to your environment.

    0 comments No comments