Incomplete files copied to a remote host with Copy-Item

Brass Contributor


I tried to copy a file (of about 1 GB) from host1 to host2 through PowerShell's Copy-Item.


host1 runs PowerShell 7.4.0 and Windows 11, host2 runs Windows 10 with its default version of PowerShell.


I enabled PSRemoting in both hosts. I added host1 in the TrustedHosts list of host2 and vice-versa. I am also able to have the host2 prompt from host1 using Enter-PSSession.


In a new PowerShell window, in host1, I ran:


$test_transfer = New-PSSession host2 -Credential host2-user
Copy-Item -ToSession $test_transfer file1.mp4 -Destination C:\Users\host2-user\


The progress has been shown, it increased till reaching the end: the transfer seemed successful. However, when trying to open the file in host2, it was incomplete and its size was of about 3 MB (while the original file1.mp4 in host1 is about 1 GB).


I tried with other files, the smaller was about 200 MB, but nothing changed: the same small, incomplete file was created in host2 and all the transfer failed this way.


Did I make any mistake? What is the correct procedure?

4 Replies



Hi, Paige.


You're using the right process - as noted below:



I don't run Windows 11 so I can't reproduce your test exactly, but between two Windows 10 hosts, I had no problems with either of the following scenarios:


  • Copying from Windows PowerShell to Windows PowerShell;
  • Copying from PowerShell 7.4.0 to Windows PowerShell.


Have you tried using the same process from Windows PowerShell on Windows 11 to Windows PowerShell on Windows 10? Or similarly, from PowerShell 7.4.0 to 7.4.0 across both machines?


I was using a 105 MB file as the test item, which while being smaller than your examples, is much larger than the 3 MB stub you are seeing.


For reference only, the commands I ran in both tests were the following:


$Session = New-PSSession -UseSSL -ComputerName "";
Copy-Item -Path ".\PowerShell-7.4.0-win-x64.msi" -ToSession $Session -Destination "C:\Data\";
Remove-PSSession -Session $Session;


Ignore my use of -UseSSL as that's unlikely to work for most people, as they tend not to set up secure WinRM. It's only included for completeness in regards to my testing.


It's only a guess, but perhaps check that something like a virus scanner on the target machine is not getting in the way.


If it's some kind of obscure problem between Windows 11 and Windows 10 though (i.e. with SMB, or perhaps even Windows PowerShell on Windows 11), then maybe someone else that runs Windows 11 can confirm that (as I cannot).






Hello Lain!

Thank you for your suggestions and for your help.


Have you tried using the same process from Windows PowerShell on Windows 11 to Windows PowerShell on Windows 10? Or similarly, from PowerShell 7.4.0 to 7.4.0 across both machines?

I tried only the first one: in host1, with Windows 11, I have Windows PowerShell 5.1 (as well as in the Windows 10 host). However, when trying from host1

$test_transfer = New-PSSession host2 -Credential host2-user

 I get an error:

New-PSSession : Cannot bind argument to parameter 'Credential' because it is null

(which I can't explain).


As regards your second attempt suggestion (from PowerShell 7.4 to PowerShell 7.4) I did not try, because I have a doubt and I wrote a separate post about it.


There is no virus scanner in host2.


Thanks for all your feedback and for testing this transfer.





Hi, Paige.


I'm honestly not sure what the issue might be, as since I cannot reproduce the issue, it leaves guessing as the only option I have.


So, you have two hosts that you've already tested with, which are:


Host 1Windows 11Has PowerShell 7.4
Host 2Windows 10Only has Windows PowerShell


If would be interesting to introduce a third host:


Host 3Windows 10 or 11Only has Windows PowerShell


And then try the copy from Host 3 back to the original Host 2.


I have no idea if this would produce a different result but it could indicate what to focus on, insofar as:


  • If the whole files copies, then I'd focus on Host 1;
  • If the whole file only copies that same 3 MB then I'd focus on Host 2.


It's really just structured guesswork but if you have a third machine, it'd be quick and worth doing.


I also have a funny feeling this might come down to which options are chosen during the PowerShell 7.4 setup, too, as I seem to recall there's some options in there around defaults (which I always unselect), but that may have exactly nothing to do with this issue. It's just an isolated thought that if I were trying to diagnose this, I might come back to after running the Host 3 scenario above.


I'm hoping someone else might have seen this before and can provide some detailed insight, as guessing doesn't inspire much confidence.






Your table is correct: it perfectly depicts the scenario.

Unfortunately I don't have a host3 available, so my tests have only been between host1 and host2.

I installed in host2 PowerShell 7.4.1 (and during the installation no options were asked to choose, so maybe the PowerShell 7.4 setup you are mentioning can be done in a separate moment) and I enabled PSRemoting also there.
Then, I made several tests between host1 and host2 (trasferring not only files from host1 to host2 but also vice-versa), specifying either

$test_transfer = New-PSSession host2 -Credential host2-user -ConfigurationName microsoft.powershell


$test_transfer = New-PSSession host2 -Credential host2-user -ConfigurationName powershell.7.4.1

so selecting which PowerShell must be used in the destination host. I didn't cover all the possible cases, but many.

This way, all the file transfers were successful, except for one case: when running PowerShell 7.4 in host1 and selecting "-ConfigurationName microsoft.powershell", so using Windows PowerShell 5.1 in host2 as receiving program. In this case, even if the transfer of a huge file (hundreds of MBs) was completed, only a 3 MB file remained in host2, unreadable.


As you previously guessed, probably this was due to a compatibility issue between PowerShell 7.4 and Windows PowerShell 5.1, when the former is used as sender and the latter as receiver (vice-versa was instead ok, at least during my tests). So I suggest to use PowerShell 7.4 in both.