File-Server Migration: Scopy Becomes Xcopy

In "Permcopy and Share.vbs File-Server Migration Tools," January 2001, I discussed some command-line tools that can help you remotely migrate a shared folder from a Windows NT 4.0 server to a Windows 2000 server. That process requires several steps. First, you need to create the new directory on the Win2K server, share that directory, and set the share permissions. Creating the directory remotely is simple—the Md command works as well on Uniform Naming Convention (UNC) names as it does on drive letters. The Microsoft Windows 2000 Resource Kit's Permcopy tool lets you set one shared directory's permissions to match another shared directory's permissions, and share.vbs lets you share a directory remotely. (At the end of my January column, I also mentioned using the Fileman command to help. I'm not sure what I was thinking, but disregard that statement; Fileman has no role here.)

Now, we need to finish the job by copying all those files and keeping their owner information and permissions intact. This problem isn't new; almost every NT administrator has faced it. And I believe that in NT, the answer was always the same—use the Microsoft Windows NT Server 4.0 Resource Kit's Scopy tool. Scopy works like Xcopy, but Scopy copies owner and ACL information as well as files and directory structures. So I was surprised to find that Scopy is no longer included in the Win2K resource kit. Instead, Win2K's Xcopy command incorporates Scopy's functionality through two new options: /O and /X. The /O option copies both owner- and file-permission information and includes that information with the file. The /X option, which works only in conjunction with /O, also transfers audit settings. So, if you've been auditing the activity on a particular file on your NT 4.0 server, you can continue to audit it on your Win2K server.

Let's wrap up our migration task with an example. Suppose my NT 4.0 file server is named \\From and its file share is named Files. I'm going to migrate Files to a share named Files on a server named \\To. To keep things interesting, let's assume that I'm not sitting at either \\From or \\To, and to keep the sample commands short, let's assume each share is on the corresponding machine's C drive.

The first step is to log on to both servers. The method I like best is the old Net Use \\servername\IPC$ /user:domainname\username trick, but you can use whatever method you like.

Next, create the directory on \\To by typing

net use X: \\to\c$
md X:\Files

at the command line. Then, tell \\To to share the C:\Files directory as \Files:

cscript share.vbs /c /n Files /s To /p C:\Files /t disk

Again, note the oddities about share.vbs—you refer to the To server as To, not as \\To. Next, use Permcopy to ensure that the permissions on the \\To\Files share are the same as those on the older \\From\Files share:

permcopy \\From Files \\To Files

Remember, as I explained in my January column, to put at least one space between \\From and Files and between \\To and Files. Finally, use Xcopy to move the files. If you want the owner information to migrate properly, Xcopy must see these moves as being from directory to directory rather than from share to share. So, we need to map to the C drive on \\From as well:

net use Y: \\From\C$
xcopy Y:\Files\* X:\Files /S /O /T

With that, we're finished. And now that I look at what we've done, I realize that I could have saved a step by going directly to Xcopy and using it instead of Net Use to create the target directory. That's the thing about Win2K: It gives you at least 20 ways to do everything.

End of Article