Error: Specified session does not exist?

Question

PowerShell

On the server, in the C:\scripts folder, there is a powershell script that:
Takes files from folders and edits the data in them, and in the second step, distributes them to remote computers.
Step 2, in a nutshell, looks like this:

Invoke-Command $remoteComp -Credential $cred -Scriprblock {
New-PsDrive -Name X -Credential $credLocal -PsProvider FileSystem -Root \\10.10.10.10\script\first\

Copy-Item -Path X:\Filename.txt -Destination C:\FileFloder\Filename.txt

Remove-Psdrive -Name X}

It is working. The file transfers well. BUT, about 2/3 of the time I get the error "The specified work session does not exist. It may have ended.”
In this case, if you restart the remote machine, or run the script again after 30 minutes, it will work correctly.
Local administrator accounts have been created on remote machines, the Enable-Psremoting -Force cmdlet has been applied, an administrator account exists on the server, and the machines with which the connection is being established are also listed in TrustedHosts. All computers are NOT in the domain. All machines are running Windows 10 and using Powershell 5.1.
Google says that maybe I'm catching a Double-Hop error (when I connect from a remote session to another remote session), but then I would not be able to work at all. But the script works stably in 1/3 of the cases, and more often I get the error “The specified session does not exist. Maybe it's over."

Answer 1

I seem to be getting the same error.
solved by entering the username through the hostname\username. hostname of the target remote machine on which to execute scriptblock. the user - the local administrator by the final remote machine.
before that, I, however, played with credssp and turned it on everywhere (enable-wsmancredssp, add the -authentication credssp key to the invoke-command). but after finding the solution above, disabled and tried again - works.
Incidentally, invoke-command seems to use Negotiate as the default authentication method. perhaps the inconsistency of the problem is caused by the fact that when "negotiating" how we will authenticate, machines are sniffed by different methods (why? I have no idea, this is just a theory) or different machines choose different methods. some work with some machines, some do not and an error pops up. it might be worth iterating over all the values ​​of the -authentication parameter in invoke-command, finding one that works every time and hard-coding it.