Is it possible to have your package source location on a server joined to a different domain than that of your SCCM primary site?

I have an SCCM environment with more than one primary site spread throughout different domains.  I would like to use the same package source server for all of them, but I get access denied when I try to add a package to a distribution point.  The primary site server's computer account has full access to the package source server, as well as the network access account.  I'm able to add the package to the DP on the primary site, but none of the other DPs.  

I tried enabling the site installation account as per another thread I ran across, but this didn't help the cause.

Does anyone have any documentation as to how permissions should be setup in this scenario.

That's odd...If you can add it to one DP you should be able to add it to all of them. The content is sent from the primary site server to the DP's not from the package source to the DP's. The site server compresses it and sends it.

Scratch that.  I'm actually not able to add it to the DP on the primary either.  I spoke too soon.

In the meantime, I've used psexec to map a drive under the system context to the package source location without an issue.  I also know that if I move the package source locally, it will work fine when I define the source via both a drive location or a network location.

The NAA has nothing to do with this nor does the site installation account.

When you say a different domain, is it the same forest or different?

Can you define exactly what you mean by "The primary site server's computer account has full access to the package source server"? That really doesn't mean anything.

The site server's computer account has full access to the package source server actually means a lot.  It means that I've made the site server an administrator of the package source server hoping that would give access by the site server's system account.  When this didn't work, I searches the forums for others in a similar situation.  That's when I came across another thread with a similar issue.  I can't paste the link in here because my account is new.  The suggestion was to enable the site installation account.  I understand this is a long shot, but I mentioned it in case someone saw this post and suggested to try it.

Apologies for not being more clear on the different domains.  The primary site server I'm having issues with is in a different forest than the package source server (with a forest trust).  I'm assuming that the access denied errors are sourcing from the fact that the local system account on the site server doesn't have access to the package source server.  The reason for the post is that I'm not sure how to overcome that and I'm wondering if anyone knows how to make this scenario work so that I don't have to maintain more than one package source server.

Local admin permissions don't actually mean anything with respect to file sharing. The site server's account must have both share level and NTFS read-permissions on the folder and its contents. This is completely independent from local admin permissions which are not in any way required for ConfigMgr to acquire source files from a location.

I can't say I've ever tried giving a computer account permissions across a forest-boundary, but that shouldn't pose any special challenges as long as the account is in the trusted domain and the server is in the trusting domain.

Have you tried to manually access the content using the server's account (you can use psexec -s to launch a command-prompt as the server's local system account).

Hi Technically it should work . Are the domains having a 2 way trust configured? http://blogs.technet.com/b/configmgrteam/archive/2010/07/09/frequently-asked-questions-about-active-directory-domains-and-forests-with-configuration-manager-2007.aspx Can you confirm that the DP has been successfully installed? Checking the sender.log on the source DP should help to provide an insigh