Shadow Copies of Shared Folders (Part 2)

Before we talk about accessing Shadow Copies from the clients, I want to talk about security and its implications when accessing and restoring Shadow Copies. The first thing to understand is that a Shadow Copy uses the security permissions that were in place when the Shadow Copy was made. That is, if you take a Shadow Copy and then add or remove a user or group’s access to a file/folder, while the current version of the file/folder will use the new permissions, any older Shadow Copies will still use the old permissions.

For example, say I want to give ddinicolo the right to read and modify Important.doc – so I modify the NTFS permissions on the file. While ddinicolo now has access to the current version of the file and any Shadow Copies taken after this point, he does not have access to any of the Shadow Copies that have already been made. Continuing with this example, let’s say two weeks have passed and ddinicolo no longer needs to access the file – so again I modify the NTFS permissions on the file, this time removing ddinicolo’s access. While ddinicolo can no longer access the current version of a file, he can still access any shadow copies of the file that were made between the time he had access and the time he no longer had access to the file (note this assumes that ddinicolo still has access to the share – if you remove ddinicolo’s access to the share or remove the share all together he can’t gain access to the previous versions).

Now if ddinicolo still has access to an older version of Important.doc from the two weeks he had access it’s probably not a big deal – the only thing you can do with a Shadow Copy is read files or copy the files to a new location if you don’t have access to the current version of the files. However there is one situation where you do need to be concerned about access to older Shadow Copies – when someone had permissions to a file that they should not have had in the first place. While it is simple to remove access to the current version of a file or folder, the same is not true about Shadow Copies. Because Shadow Copies are read only (i.e. you can’t delete a specific file/folder inside of a Shadow Copy or modify its permissions), the only way you can remove a user or group’s access to a previous version of a file that they did have access to at the time is to delete the Shadow Copy/Copies, or remove the user/group’s access to the entire share (note that I’m talking about denying/removing read access using share permissions here, not NTFS).

So, in order to “View” a previous version of a file/folder you need at least read access to the file/folder at the time the Shadow Copy was made. To “Copy” a previous version of a file/folder you need at least read access to the file/folder at the time the Shadow Copy was made and additionally write access to the location where you are copying the file/folder to. To “Restore” a previous version of a file/folder you need at least read access to the file/folder at the time the Shadow Copy was made and additionally write access to the location where the file/folder was originally located (i.e. where the file is being restored to).

As far as permissions of files go after a restore operation, they retain the same permissions they had before the restore operation. That is, if you restore a file from a previous version and a current version of the file still exists, after the file is overwritten it will retain the permissions of the file that was overwritten – not the permissions on the previous version. So, let’s say the current version of a file no longer allowed ddinicolo access, but the previous version of a file does. If we restore the previous version the current permissions for the file will be used – which don’t allow ddinicolo access. Similarly, if we restore a file that no longer exists the file/folder will inherit the permissions of its parent folder – not the permissions on the previous version. Again, restore is just like a copy/paste operation from the previous version to the current version.

With all that out of the way let’s talk about clients. In order for a system that is not running Windows Server 2003 to access Shadow Copies it must have the SCSF client installed. However, it is important to note that the server side of Shadow Copies of shared Folders will work with any client that can access a share on a Windows Server 2003 system – because the creation is all done on the server side. In other words, the creation of Shadow Copies is entirely server based and does not require that the client be running any special software. So, if the user does not have the SCSF client installed on their system they will need to use another system that does have the SCSF client installed (or have the administrator restore the file from the server…but this does not take advantage of SCSF’s “let the user do it” feature – that is why it’s recommended you make the client available on at least some workstations).

Their is a copy of the SCSF client for Windows XP available in %systemroot%\System32\Clients\Twclient\X86 on a Windows Server 2003 server. However, a more recent version of the client is available from http://www.microsoft.com/windowsserver2003/downloads/shadowcopyclient.mspx, so I recommend you go ahead and download and use the client from the above address. The client currently supports Windows XP and Windows 2000 at the time this article was written (Microsoft’s documentation has also talked about supporting Windows 98).

To provide compatibility with versions of Windows earlier than Windows XP you must first run the SCSF client setup on the server. The installation is quick – launch the MSI you downloaded, click next on the Welcome screen, accept the Licensing Agreement and click next, and then click Finish after the installation is done.

You can then repeat the installation on your Windows 2000 Pro and Windows XP Pro workstations. Alternatively, you can use the software installation portion of Group Policy (assigning it to computers) if you are running Active Directory.

After the client is deployed the Previous Versions tab will be available on the file or folder’s properties for any shared folder stored on a volume with SCSF enabled. If you remember back to part one of SCSF I said that in this example that E: contained My Documents folders redirected in group policy (using an UNC path). Here is what that looks like – the operation of the client is exactly the same as on the server:

One last note about SCSF – it will work on a server cluster. You should read “Using Shadow Copies of Shared Folders in a server cluster” in the Windows Server 2003 documentation (it is located in %systemroot%\Help\mscsconcepts.chm and then “shadow copies” in the Index) before you configure SCSF on a cluster.

Well that wraps up our look at Shadow Copies of Shared Folders. While this article is geared for network administrators – detailing all the ins and outs of SCSF – SCSF is something that can be used by end users. Using SCSF to restore or view a previous version of a single file is a simple operation that someone can learn with only five clicks. Restoring files from the previous version of a folder is slightly more complicated, but should not be a problem for anyone who knows how to move files from one folder to another.