Rapid Recovery has a cool restore-with-permissions context feature. In theory, this works like this:
* you highlight and right click on the files or folders to be restored and
* choose copy from the context menu,
* navigate to the new location,
* right click again,
* choose "copy with permissions" from the context
and the data is copied while preserving permissions.
This works well in most cases. However if you attempt restoring files or folders for which you do not have permissions, or you are trying to restore many gigabytes of data you may not be successful. There are ways of going around these limitations such as taking ownership and adding yourself to the various ACLs (while making notes and restoring the previous permissions after the restore) and dividing the restore job into smaller batches but this is a tedious approach.
You need a simpler, fail safe method for these restores.
PowerShell Scripting Disclaimer:
This script is provided "as is" for the purpose of illustrating how product tasks may be performed in conjunction with PowerShell. Support shall not be liable for any direct, indirect, incidental, consequential, or other damage alleged in connection with the furnishing or use of this script or of the principles it demonstrates. See PowerShell Scripting Support for more information.
To streamline the issue a PowerShell script has been created. To work around the permissions issue, all operations performed by the script are run while impersonating the NT AUTHORITY\SYSTEM account. Since the SYSTEM account is supposed to have by default access to all data, this circumvents the permissions issue. There are four ways of impersonating the System account: Windows Services, Windows processes, Scheduled Tasks and Mark Russinovich's PSExec.exe. This script uses the most straightforward method of impersonation -- launches processes under the System Account.
The script is a wrapper for robocopy.exe (a built-in windows utility) and features a simple Text User Interface that allows selecting the folders and/or files to be restored, the destination path, the path where the logs are to be located, the number of threads to be used and at last but not at least to run the job. To simplify the selections, GUI elements based on the WindowsAPICodePack have been used. As such, the script comes packaged with two DLLs: Microsoft.WindowsAPICodePack.Shell.dll and Microsoft.WindowsAPICodePack.dll which are components of the WindowsAPICodePack package.
The script Text User Interface looks like below.
Please note that the entered data can be altered if mistakes have been performed or reused (i.e. there are several restores to be made in the same target folder). To clear an entry, bring up the file/folder selection dialog and choose "Cancel".
Logging involves selecting the path and entering a file name that will be used as a prefix for the restore operation. If multiple folders are selected for the restore operation, a separate log is created for each by using the provided file name as a prefix to which the folder name is attached (i.e. if the prefix is Mylog.log and the folders to be restored are MyFolder1 and MyFolder2, two logs called MyLog_MyFolder1.log and MyLog_MyFolder2.log are created). If discrete files are restored the the prefix and the word "files" to determine the log name ((i.e. if the prefix is Mylog.log, the log showing the results of the operation will be Mylog_files.log).
The script needs to be launched from a Powershell 3.0 or later administrative (elevated) console.
