Fix 0X0000094F: Source and destination on different servers

Quick Answer (for the impatient)

Run the copy command or map the drive under the same user account on both servers. Use net use with explicit credentials if needed. The error fires when Windows sees the source and target are on different machines but the user context doesn't match.

Why Your Files Won't Cross the Server Boundary

You're probably seeing this error when trying to copy a file from \\ServerA\Share to \\ServerB\Share, or when running a backup script or migration tool. The error code 0X0000094F maps to NERR_DifferentServers, which is a network error that means Windows decided the source and destination are on physically different servers and your current credentials don't have access to both.

Had a client last month who was moving a file server from SBS 2011 to Server 2022. Their robocopy script kept failing with this error. The culprit? They were running the script under the SYSTEM account on the source server, which didn't have permissions on the destination. Once we switched to a domain admin account, it worked instantly.

Windows SMB handles cross-server operations by checking if the user token that authenticated to the source can also authenticate to the destination. If the computer account on the source server is trying to access a share on the destination server, it'll get this error unless there's a trust or explicit permissions set.

Step-by-Step Fix

Check if both servers are in the same domain or trusted domain. If not, you'll need to authenticate separately. Open PowerShell as admin on the source server and run:
```
Test-ComputerSecureChannel -Repair
```
If that fails, you have bigger authentication issues.
Run the operation under a domain account that has permissions on both servers. Don't use SYSTEM or local accounts. In Task Scheduler, specify a domain user. For command-line work, use:
```
runas /user:DOMAIN\AdminUser "cmd.exe"
```
Then run your copy command from that elevated prompt.
Use explicit credentials with net use. Before copying, map a drive to the destination server with the correct user:
```
net use Z: \\ServerB\Share /user:DOMAIN\AdminUser Password123
```
Then copy files to Z: instead of the UNC path.
If using robocopy, add the /COPYALL and /SEC flags. Also ensure you're running robocopy with the correct account. Worked example:
```
robocopy \\ServerA\Share \\ServerB\Share /E /COPYALL /SEC /R:2 /W:5 /MT:4
```
The /MT flag can cause this error if threads use different credentials, so drop it to /MT:1 if it still fails.

Alternative Fixes When the Main One Doesn't Work

If the above steps don't resolve it, try these:

Map drives locally first. On the source server, map a drive to the destination share. Then copy from local path to local path. Example: copy C:\Temp to Z: (where Z: maps to \\ServerB\Share). This bypasses the cross-server check because Windows sees one local path.
Check SMB signing and encryption settings. If the servers have mismatched SMB protocols (e.g., source is SMB1, destination requires SMB3), you'll get authentication failures that show as this error. Run on both servers:
```
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, RequireSecuritySignature, EncryptData
```
Match the settings. Disable SMB1 if it's on (it should be off unless you're supporting old hardware).
Use a temporary staging location. Copy the files to a local folder on the source, then copy from that folder to the destination. Stupid workaround, but I've had cases where permissions were so tangled this was the only reliable path.
Verify the destination server's firewall. Port 445 must be open inbound. Quick test from source:
```
Test-NetConnection -ComputerName ServerB -Port 445
```
If that fails, the error may actually be a connectivity issue misreported as this error code.

Prevention Tips

To avoid this error in the future:

Always run file copy operations between servers under the same domain user account with explicit file permissions on both sides. Never rely on SYSTEM or network service accounts for cross-server file moves.
Use DFS replication if you need ongoing file synchronization across servers — it handles the authentication and conflict resolution better than manual copies.
For automated backups or migrations, use a dedicated service account with 'Log on as a batch job' rights and explicitly grant it Full Control on both source and destination shares. Test it with a small folder first.
Keep your SMB versions consistent across the network. If you've got a mix of Server 2012 and Server 2022, force the older ones to use SMB2 or higher. I've seen this error pop up when SMB dialect negotiation fails silently.