Windows Copy Large Files Over Network in Windows 10/7 (Best Way)

Looking for the best way to copy large files over network in Windows 7/10? This article tells how to let Windows copy large files to another drive or computer over network in simple way.

By Teresa / Last Updated August 4, 2020

Want Windows to Copy Large Files over Network

«I’d like to transfer some of my videos files, in large size, from my Windows 7 64 bit to another computer which is connected my LED TV. The two machines are in the same segment of LAN, and I guess I could transfer them over network cause I don’t have a suitable external storage to transfer them manually. But the network approach is really slow. Is there any way to do it faster? Thanks.”

Transferring large files from one location to another is unavoidable nowadays when everything is moving towards refinement. Photos become larger because it needs more clearer, and video files become larger because it needs better experience.

The development of network also makes connecting to each device easier. Transferring files from PC to PC or other devices over network is not uncommon is our daily life, includes large files. Nevertheless, users always complain that all kinds of troubles emerge while copying large files via network.

Problems Copying Large Files over Network

Two most common problems of copying large files from network would be operation failed or slow transmission speed. In general, there is several reasons most likely account for the phenomena.

Bad network connection. This would be the main reason for copying large files over network slow.

4 GB file limitation. The partition that is formatted with FAT32 file system has the limitation for a single file larger than 4GB. Therefore, you may get Windows 7 copy large files over network fails issue if the destination path is a FAT32 drive. It is suggested to convert FAT32 to NTFS without losing data to solve the problem.

File is occupied or corrupted. A damaged file is possibly not recognized by the Windows transfer tool, which results in the entire process hanging and waiting for further instruction.

File conflicts. A conflict file appears when multiple versions of files or folders attempt to be copied to a single file or folder.

Absolutely, there should be other problems and corresponding causes in copying large files. But more importantly, it is time to figure out a better way to do the large files copying over network.

How to Copy Large Files over Network in Windows 10/8/7?

To complete the task easily, you’ll need the help of AOMEI Backupper Standard, free yet powerful file sync software. In a nutshell, it will help you sync large files to a network share and then you can access these files from other computers. Here are detailed steps.

Step 1. Create network share folder

Two ways are available for this goal, Command Prompt and File Explorer. To create share in Command Prompt, type net share = :

/remark=» » and press Enter. For example, type net share Teresa=c:\data\johndrv /remark=»Teresa’s drive» and hit Enter.

To create share in Windows File Explorer, please follow these steps. First, open File Explorer, right click a directory and select “sharing”. Second, click the Sharing tab and select “Shared as”. Finally, enter a description if you like and click OK. You’ll see a path of the share folder in the window. Plus it with the computer’s network ID, eg. \\192.168.XX.XX. Remember it.

Now, make sure the other computer is able to access the share folder. Let’s continue.

Step 2. Sync large files to network share folder

Notice: if the share folder happens to contain all large files you’d like to copy, you can access the folder from other devices and do the copying directly. If not, please move files to the network share folder and try again.

1. Free download, install and run AOMEI Backupper Standard on the computer where you created share folder.

2. Click “Sync” and then “Basic Sync” in AOMEI Backupper.

3. Click “Add Folder” to select the folder where the large files stored.

4. Click «Select a network location» to add a network path. Go “NAS/Share” > “Add Network Location” to input the created network shared path.

5. Preview the operation and click “Start Sync”. Wait for the process to complete.

Tips: to sync files in real time, please upgrade to Professional edition or higher.

Step 3. Access files from anther computer

Set the permission of share folder to “Everyone” and then it can be access to any other computer that is using the same LAN.

Press Windows key + R key to summon Run box. Input the path of the shared folder and you’ll be able to copy files to local disk. Just make sure the destination partition is formatted with NTFS file system.

Summary

When you get problems copying large files over network in Windows, you can try a different tool instead of Windows built-in utility. AOMEI Backupper does a great job in syncing all kinds of files. It is also embeds with backup and clone feature to protect Windows or upgrade old hard drives. Go for it and have a try.

Copy from network share windows

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I want to setup a GPO to copy paste files (achieving what the title states, preferably avoiding scripting). Can anyone suggest how this is done?

Answers

All replies

I f I have understood correctly,
you want to copy files from your server to a network location?

You can use GPP to copy files.

If you press F3 you will see the environment variables you can use.
http://www.group-policy.com/gp%5Cshortcuts.smp

MVP Group Policy — Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let’s go, use GPO!

I meant vice versa. IE

File-server has an exe on a shared folder

Copy this file to C:\Windows on every other server

Thanks for posting in Microsoft TechNet forums.

I understand that you hope to use group policy to copy an .exe file from shared folder to each server.

We can realize that by using GPP.

Please check the information in the thread below:

Group policy preferences copy files

If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here .

I think I have configured this.My GPO is as follows:

Not sure why that image got cut off, but that’s the settings. Is that correct?

I guess J: is the mapped drive?

J: won’t work, you have to use the UNC path \\server\share.

Are you talking about User Configuration or Computer Configuration?

If you use User Configuration, you can choose if it should run the the security context of the user or not.
http://technet.microsoft.com/en-us/library/cc772371.aspx

If you use the security context of the user, he might not be able to write to the C:\Windows folder.

So what you should do, do not check the security context of the user (or use Computer Configuration) and use the UNC path.

(you will also have to verfiy that the SYSTEM account is able to access the share. )

MVP Group Policy — Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let’s go, use GPO!

Windows Clients using a cached copy of .Net 4.0 exe located on a network share drive

We have a .Net 4.0 executable (MyProg.exe) and associated dlls that are deployed on a network share using XCopy. MyProg.exe and its dlls are all unsigned.

We have them installed on the network share so multiple users can use the same version of the program and to ease updating the program. This worked well for many of our customers for many years now.

For a recent customer, a folder on Windows Server 2012 Virtual Machine is shared as a network folder. Users run the program from another terminal server (Windows Server 2012).

When we updated the MyProg.exe (to version 2.0 from 1.0), the terminal server does not run the new executable until it is restarted. It continues to load version 1.0 even though that exe is no longer available. It appears to be running a cached version of MyProg.exe V1.0.

1. The steps I tried:
   1. Close all instances of the program
   2. Copy the new MyProg.exe to the folder and overwrite the files (Updated exe version from 1.0 to 2.0)
   3. Verify version 2.0 of the MyProg.exe from its Properties >> Details page both from file-server and terminal server
   4. Verify that the MyProg.exe V2.0 runs when executed from the file-server using shortcut file (target: \\Server\MyProg\MyProg.exe)
   5. Run the same shortcut file (target: \\Server\MyProg\MyProg.exe) from terminal server and MyProg.exe V1.0 starts
   6. Rename \\Server\MyProg to \\Server\ MyProg1 and confirm that terminal server can not run the shortcut because that folder no longer exists.
   7. Create a new shortcut file (Traget: \\Server\MyProg1\MyProg.exe) and confirm that MyProg.exe V2.0 runs on the client
   8. Rename the folder \\Server\MyProg1 back to \\Server\MyProg and running the original shortcut file continues to load MyProg.exe V1.0 until the terminal server is restarted.
   9. I verified that offline files is disabled on terminal server
   10. I verified that I can not overwrite the MyProg.exe executable when the program is running on Terminal server.

What else can I check to troubleshoot why an older version of the executable is being executed even when that file no longer exists?

Copy from network share windows

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

General discussion

1. Introduction

The Server Message Block (SMB) Protocol is a network file sharing protocol, and as implemented in Microsoft Windows is known as Microsoft SMB Protocol. The set of message packets that defines a particular version of the protocol is called a dialect. The Common Internet File System (CIFS) Protocol is a dialect of SMB. Both SMB and CIFS are also available on VMS, several versions of Unix, and other operating systems.

Microsoft SMB Protocol and CIFS Protocol Overview

Server Message Block overview

1.1 SMB Versions and Negotiated Versions

There are several different versions of SMB used by Windows operating systems:

• CIFS – The ancient version of SMB that was part of Microsoft Windows NT 4.0 in 1996. SMB1 supersedes this version.
• SMB 1.0 (or SMB1) – The version used in Windows 2000, Windows XP, Windows Server 2003 and Windows Server 2003 R2
• SMB 2.0 (technically SMB2 version 2.002) – The version used in Windows Vista (SP1 or later) and Windows Server 2008 (or any SP)
• SMB 2.1 ((technically SMB2 version 2.1) – The version used in Windows 7 (or any SP) and Windows Server 2008 R2 (or any SP)
• SMB 3.0 (or SMB3) – The version used in Windows 8 and Windows Server 2012
• SMB 3.02 (or SMB3) – The version used in Windows 8.1 and Windows Server 2012 R2

Windows NT is no longer supported, so CIFS is definitely out. Windows Server 2003 R2 with a current service pack is under Extended Support, so SMB1 is still around for a little while. SMB 2.x in Windows Server 2008 and Windows Server 2008 R2 are under Mainstream Support until 2015. You can find the most current information on the support lifecycle page for Windows Server . The information is subject to the Microsoft Policy Disclaimer and Change Notice . You can use the support pages to also find support policy information for Windows XP, Windows Vista, Windows 7 and Windows 8.

In Windows 8.1 and Windows Server 2012 R2, we introduced the option to completely disable CIFS/SMB1 support, including the actual removal of the related binaries. While this is not the default configuration, we recommend disabling this older version of the protocol in scenarios where it’s not useful, like Hyper-V over SMB. You can find details about this new option in item 7 of this blog post: What’s new in SMB PowerShell in Windows Server 2012 R2 .

Negotiated Versions

Here’s a table to help you understand what version you will end up using, depending on what Windows version is running as the SMB client and what version of Windows is running as the SMB server:

Windows 8.1 WS 2012 R2

Windows 8 WS 2012

Windows 7 WS 2008 R2

Windows Vista WS 2008

Windows 8.1 WS 2012 R2

SMB 3.02

SMB 3.0

Windows 8 WS 2012

SMB 3.0

SMB 3.0

Windows 7 WS 2008 R2

Windows Vista WS 2008

* WS = Windows Server

1.2 Check, Enable and Disable SMB Versions in Windows operating systems

In Windows 8 or Windows Server 2012 and later, there is a new PowerShell cmdlet that can easily tell you what version of SMB the client has negotiated with the File Server. You simply access a remote file server (or create a new mapping to it) and use Get-SmbConnection.

To enable and disable SMBv1, SMBv2, and SMBv3 in Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012, please follow the steps in the article below.

Warning: We do not recommend that you disable SMBv2 or SMBv3. Disable SMBv2 or SMBv3 only as a temporary troubleshooting measure. Do not leave SMBv2 or SMBv3 disabled.

1.3 Features and Capabilities

Here’s a very short summary of what changed with each version of SMB:

From SMB 1.0 to SMB 2.0 — The first major redesign of SMB

• Increased file sharing scalability
• Improved performance
  • Request compounding
  • Asynchronous operations
  • Larger reads/writes

More secure and robust

• Small command set
• Signing now uses HMAC SHA-256 instead of MD5
• SMB2 durability

From SMB 2.0 to SMB 2.1

• File leasing improvements
• Large MTU support
• BranchCache

From SMB 2.1 to SMB 3.0

• SMB Transparent Failover
• SMB Witness
• SMB Multichannel

• SMB Scale-Out
• SMB Direct (SMB 3.0 over RDMA)
• SMB Multichannel
• Directory Leasing
• BranchCache V2

VSS for Remote File Shares

• SMB Encryption using AES-CCM (Optional)
• Signing now uses AES-CMAC

• SMB PowerShell
• Improved Performance Counters
• Improved Eventing

From SMB 3.0 to SMB 3.02

• Automatic rebalancing of Scale-Out File Server clients
• Improved performance of SMB Direct (SMB over RDMA)
• Support for multiple SMB instances on a Scale-Out File Server

You can get additional details on the SMB 3.02 improvements in Windows Server 2012 R2 at http://technet.microsoft.com/en-us/library/hh831474.aspx

1.4 Related Registry Keys

• HKLM\SYSTEM\CurrentControlSet\Services\MrxSmb\Parameters\

• DeferredOpensEnabled – Indicates whether the Redirector can defer opens for certain cases where the file does not really need to be opened, such as for certain delete requests and adjusting file attributes. This defaults to true and is stored in the Redirector variable MRxSmbDeferredOpensEnabled.

• OplocksDisabled – Whether the Redirector should not request oplocks, this defaults to false (the Redirector will request oplocks) and is stored in the variable MrxSmbOplocksDisabled.

• CscEnabled – Whether Client Side Caching is enabled. This value defaults to true and stored in MRxSmbIsCscEnabled. It is used to determine whether to execute CSC operations when called. If CSC is enabled, several other parameters controlling CSC behavior are checked, such as CscEnabledDCON, CscEnableTransitionByDefault, and CscEnableAutoDial. CSC will be discussed in depth in its own module, so will be only mentioned in this module when it is necessary to understanding the operation of the Redirector.

• DisableShadowLoopback – Whether to disable the behavior of the Redirector getting a handle to loopback opens (opens on the same machine) so that it can shortcut the network path to the resource and just access local files locally. Shadow opens are enabled by default, and this registry value can be used to turn them off. It is stored in the global Redirector variable RxSmbDisableShadowLoopback.

• IgnoreBindingOrder – Controls whether the Redirector should use the binding order specified in the registry and controlled by the Network Connections UI, or ignore this order when choosing a transport provider to provide a connection to the server. By default the Redirector will ignore the binding order and can use any transport. The results of this setting are stored in the variable MRxSmbObeyBindingOrder.

• HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\

• Security Signature settings – The RequireSecuritySignature setting is stored in MRxSmbSecuritySignaturesRequired, EnableSecuritySignature in MRxSmbSecuritySignaturesEnabled, RequireExtendedSignature in MRxSmbExtendedSignaturesRequired, and EnableExtendedSignature in MRxSmbExtendedSignaturesEnabled. Note that the Extended Security Signatures assume the regular security signatures are enabled, so those settings are adjusted if necessary based on the extended settings. If extended signatures are required, regular signatures have to be required.

• EnablePlainTextPassword – Support for using plain text passwords can be turned on using this key. They are disabled by default.

• OffLineFileTimeoutIntervalInSeconds – Used to set the expiration time for timing out an Exchange (discussed later) when the exchange is accessing an offline file. This value defaults to 1000 seconds, but can be changed in the registry and is stored in the global Redirector variable OffLineFileTimeoutInterval

• SessTimeout – This is the amount of time the client waits for the server to respond to an outstanding request. The default value is 60 seconds (Windows Vista). When the client does not receive the response to a request before the Request Expiration Timer expires, it will reset the connection because the operation is considered blocked. In Windows 8, the request expiration timer for the SMB 2 Negotiate is set to a smaller value, typically under 20 seconds, so that if a node of a continuously available (CA) cluster server is not responding, the SMB 3.0 client can expedite failover to the other node.

• ExtendedSessTimeout – Stored in the ExtendedSessTimeoutInterval variable, this value is used to extend the timeout on exchanges for servers that require an extended session timeout as listed in the ServersWithExtendedSessTimeout key. These are third party servers that handle SMB sessions with different processes and vary dramatically on the time required to process SMB requests. The default value is 1000 seconds. If the client is running at least Windows 7 and ExtendedSessTimeout is not configured (By Default), the timeout is extended to four times the value of SessTimeout (4 * SessTimeout).

• MaxNumOfExchangesForPipelineReadWrite – This value is used to determine the maximum number of write exchanges that can be pipelined to a server. The default is 8 and the value is stored in the variable MaxNumOfExchangesForPipelineReadWrite.

• Win9xSessionRestriction – This value defaults to false, but is used to impose a restriction on Windows 9x clients that they can only have one active non-NULL session with the server at a time. Also, existing session based connections (VNETROOTS) are scavenged immediately, without a timeout to allow them to be reused.

• EnableCachingOnWriteOnlyOpens – This value can cause the Redirector to attempt to open a file that is being opened for write only access in a manner that will enable the Redirector to cache the file data. If the open fails, the request will revert back to the original requested access. The value of this parameter defaults to false and is stored in the MRxSmbEnableCachingOnWriteOnlyOpens variable.

• DisableByteRangeLockingOnReadOnlyFiles – This parameter defaults to false, but if set to true will cause level II oplocks to automatically be upgraded to batch oplocks on read-only files opened for read only access. It is stored in the variable DisableByteRangeLockingOnReadOnlyFiles.

• EnableDownLevelLogOff – False by default, this value controls whether a Logoff SMB will be sent to down-level servers when a session is being closed. If this is false, and the server has not negotiated to the NT SMB dialect or does not support NT Status codes, the logoff will not be sent because we aren’t sure that server will understand the request. The value is stored in MrxSmbEnableDownLevelLogOff.

• HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\

• ResilientTimeout – This timer is started when the transport connection associated with a resilient handle is lost. It controls the amount of time the server keeps a resilient handle active after the transport connection to the client is lost. The default value is 300 seconds (Windows 7, Server 2008 R2, 8, Server 2012).

• DurableHandleV2TimeoutInSecond – This timer is started when the transport connection associated with a durable handle is lost. It controls the amount of time the server keeps a durable handle active after the transport connection to the client is lost. The default value is 60 seconds (Windows 8, Windows Server 2012). The maximum value is 300 seconds.

• HKLM\SYSTEM\CurrentControlSet\Services\SMBWitness\Parameters\

KeepAliveInterval – This functionality was introduced for SMB 3.0 in Windows 8 and Windows Server 2012. The witness protocol is used to explicitly notify a client of resource changes that have occurred on a highly available cluster server. This enables faster recovery from unplanned failures, so that the client does not need to wait for TCP timeouts. The default value is 20 minutes (Windows 8, Windows Server 2012).

• HKLM\System\CurrentControlSet\Services\SmbDirect\Parameters\

• ConnectTimeoutInMs – Establish a connection and complete negotiation. ConnectTimeoutInMs is the deadline for the remote peer to accept the connection request and complete SMB Direct negotiation. Default is 120 seconds (Windows 8).

• AcceptTimeoutInMs – Accept negotiation: The SMB Direct Negotiate request should be received before AcceptTimeoutInMs expires. The servers starts this timer as soon as it accepted the connection. Default is 5 seconds (Windows 8).

• IdleConnectionTimeoutInMs – This timer is per-connection. It is the amount of time the connection can be idle without receiving a message from the remote peer. Before the local peer terminates the connection, it sends a keep alive request to the remote peer and applies a keep alive timer. Default is Default: 120 seconds (Windows 8).

• KeepaliveResponseTimeoutInMs – This attribute is per-connection. It defines the timeout to wait for the peer response for a keep-alive message on an idle RDMA connection. Default is 5 seconds (Windows 8).

• CreditGrantTimeoutInMs – This timer is per-connection. It regulates the amount of time that the local peer waits for the remote peer to grant Send credits before disconnecting the connection. This timer is started when the local peer runs out of Send credits. Default is 5 seconds (Windows 8).

[MS-SMB]: Server Message Block (SMB) Protocol

SMB 2.x and SMB 3.0 Timeouts in Windows