Friday, October 22, 2010

TFS 2010 Backup Power Tool - Grant Backup Plan Permission Failed

Now that TFS Power Tools has been released we can take advantage of the Team Foundation Server Backup feature that makes backing up TFS so much easier than it used to be.

The TFS Power Tools contain tools client side too, it's just the backup feature is designed to actually run on the TFS server itself.

It supports backing up not only all your collections but also your Reporting Server database (if using SQL Server Reporting Services integration) and your SharePoint databases if using MOSS for enhanced reporting. It works very much like the standard Windows Server Backup utility that is shipped with Windows Server 2008 R2.

You have an option specify how many copies of the backup to keep. You have to backup to a network location. You can't backup to local disk like you can with Windows Server Backup. This tool is designed to worry about backing up TFS so you don't have to.

The tool integrates with the Team Foundation Server Administration Console. So you create a backup plan from within there. You can specify when the backup should run i.e. daily, weekly, time of day etc. It can run under a domain or local account to.

There are a few articles out there that step you through the process of setting this up so I'm not going to do it here. Instead I came across a nice "issue" with it when setting it up that I thought might save other people time as I burnt quite a bit of time on this. Here is a very good example of this: http://myalmblog.com/2010/09/12/tfs-2010-power-tools-tfs-backup-and-restore-hands-on-lab/

So my issue was when getting to the end the readiness checks were failing with the Grant Backup Plan Permissions step. Which was weird as I had write access to the UNC path to which the backup was writing. The other strange thing was I discovered a file in the UNC path after running this readiness check.

After investigating further and looking at the log file (snip copied here) I figured out what was wrong:
Error  @15:35:29.014] System.UnauthorizedAccessException: Access to the path '\\server\backup\TFSBackups\Tfs_Configuration_20101022163528.bak' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.Delete(String path)
at Microsoft.TeamFoundation.PowerTools.Admin.Helpers.BackupFactory.TestBackupCreation(String path)
[Error @15:35:29.060] !Verify Error!: Account DOMAIN\user failed to create backups using path \\server\backup\TFSBackups
[Info @15:35:29.060] "Verify: Grant Backup Plan Permissions\Root\VerifyDummyBackupCreation(VerifyTestBackupCreatedSuccessfully): Exiting Verification with state Completed and result Error"
[Info @15:35:29.060] !Verify Result!: 5 Completed, 0 Skipped: 4 Success, 1 Errors, 0 Warnings
Notice what it is doing yet!? It basically writes a file to the UNC path to check for write permissions - BUT not as the service account, it uses the current logged on user account (this is a bug I'm sure). But what is failing is actually the deletion of the file.

Because of this the readiness checks fail and you can't continue. After looking at the permissions (or should I say IT looking at the permissions) it turns out I didn't have Delete permission for the current logged on user for that UNC path. Once setting the Delete permission to true, the problem went away and now I have a successful backup plan in place!

6 comments:

Anonymous said...

Another reason for this failure is if the share name contains spaces!

Simon Hart said...

I think the tool does support spaces, as per the Win32 API in the case of spaces in the path you need to use "quotes" around the path.

Cheers
Simon

PASSOUNAUD said...

Thanks for your help, adding write permissions to the account executing MSSQL service, on the backup UNC path did the trick !!!

Edward said...

Hi Simon,
I have ACCESS DENIED when using TFS power tool management, but nobody has explained why...?

Can you please take a quick look here??

http://social.msdn.microsoft.com/Forums/nl-BE/tfspowertools/thread/add75f6f-2fab-4124-9e6a-5b3ca04deb74

Anonymous said...

On my system I needed to add permission on the share for the SQL Server. I added both the SQL server and the domain SQL account.

Simon Hart said...

Thanks Anon for posting your solution...