From what I have found out, I think that the issue is with the way that BitsTransfer works. It only works interactively (i.e. as a logged on and active user). From Microsoft's documentation:
When you use *-BitsTransfer cmdlets from within a process that runs in
a noninteractive context, such as a Windows service, you may not be
able to add files to BITS jobs, which can result in a suspended state.
For the job to proceed, the identity that was used to create a
transfer job must be logged on. For example, when creating a BITS job
in a PowerShell script that was executed as a Task Scheduler job, the
BITS transfer will never complete unless the Task Scheduler's task
setting "Run only when user is logged on" is enabled. -Using Windows PowerShell to Create BITS Transfer Jobs
After I did some testing, this means that the issue is not with cross-domain authentication (which I assume you have the correct trusts etc. working), but with Bits using the login for authentication.
So, we get the following kinds of issues (using contoso\user who doesn't have access and contoso/admin who does) and specifying the credential parameter:
- Logged on as contoso\user, Credential = contoso\user, Start-BitsTransfer = Error: Cannot find path
- Expected. contoso\user does not have access.
- Logged on as contoso\user, Credential = contoso\admin, Start-BitsTransfer = Error: Cannot find path
- This is the error message that you are getting. Basically it doesn't use the Credential parameter as expected.
- Logged on as contoso\admin, Credential = contoso\admin, Start-BitsTransfer = Success.
- This is expected. Credential parameter not even needed.
- Logged on as contoso\admin, Credential = contoso\user, Start-BitsTransfer = Success.
- Was really baffled by this one, even checked the security logs, and found that sure enough EventID 4624, it used the currently logged on user, contoso\admin, to log onto the remote machine to access the file, not the credential parameter.
Now for trying out some runas workarounds. While logged in as contoso\user:
runas /user:contoso\admin powershell.exe ran Start-BitsTransfer = Error: Start-BitsTransfer : The operation being requested was not performed because the user has not logged on to the network. The specified service does not exist. (Exception from HRESULT: 0x800704DD)
- This was very unexpected. Even tried with a
-Credential, same result.Doing a runas is as if you are logged on as the other user, but I suppose you may need a profile... lets try that next.
runas /profile /user:contoso\admin powershell.exe ran Start-BitsTransfer = Error: Start-BitsTransfer : The operation being requested was not performed because the user has not logged on to the network. The specified service does not exist. (Exception from HRESULT: 0x800704DD)
- That also was unexpected... running out of ways to runas... but there is one more runas pararmeter - the netonly:
runas /netonly /user:contoso\admin powershell.exe ran Start-BitsTransfer = Error: Start-BitsTransfer : Access is denied.
- This is probably the most surprising because it actually gives us a different error message.
Finally, to the workaround. Ran the following:
$c = Get-Credential -UserName 'consoso\admin'
net use \\server\c$
Start-BitsTransfer -Credential $c -source \\server\c$\test.txt -destination .
#Success
net use \\server\c$ /delete
#Error: Cannot find path
(of course using contoso\admin for the net use command)
The reasoning is that the net use command actually logs you onto the server. Once you have that kerberos ticket it works because it has cached the admin credentials, and uses those to access the file. For a similar solution see: copy-item With Alternate Credentials
Basically, it looks like there is a bug with the Bits transfer, and it doesn't handle the -Credential property as expected. Instead it seems that it will always default to using the currently logged in user for authentication, with the exception of you manually doing a net use command to manually form the connection yourself.
