SharePoint Batch Site Manager fails when moving Site Collection 'An error occured in stsadm.exe while moving the site. Access denied.'

Over the past day or so, I have been testing the Batch Site Manager feature of the SharePoint administration toolkit v 3.0.

Firstly, I don't have or wish to install MOSS/WSS SP2 unless it is forced upon me (lots of custom features etc which will stop working in true SharePoint fashion) which is why I didn't use v4.0 of the Administration Toolkit.

When attempting to perform a 'Move' operation with Batch Site Manager, the timer job simply disappeared and the site collection remained in the original content database.

My first port of call was the \LOGS folder in the 12 hive. BSM creates a log file, e.g. BSM_2010-4-14.log. This log file was populated with the following error:

Job Title: BSM Move Job - 4/14/2010 10:05:18 AM

Job Description:

Start Time: 4/14/2010 10:05:31 AM

http://####/sites/IT -- Operation FAILED: Microsoft.SharePoint.SPException: An error occured in stsadm.exe while moving the site. Access denied.

at Microsoft.Office.Server.ESCM.ESCMMoveJob.Backup(Uri Src)

at Microsoft.Office.Server.ESCM.ESCMMoveJob.JobTaskExecute(String SiteUrl)

at Microsoft.Office.Server.ESCM.ESCMJob.Execute(Guid targetInstanceId)

End Time: 4/14/2010 10:05:57 AM

I then enabled verbose logging and checked the trace log, however there were no errors relating to this problem.

I tried all the suggestions available to me via Google, which involved adding myself as a Site Collection Administrator, and check the trace logs, of which neither worked.

Before giving up, I tried one changing the service account of the 'SharePoint Timer Service' to that of the farm admin account (which was also configured as the Site Collection Administrator), and restarted the service.

I then fired off the BSM move job again, and everything worked perfectly!

It is worth noting that as I was using this tool for testing, it was on my development environment, which consists of a 'stand-alone' SharePoint installation... Therefore the timer service was configured to log on as 'NETWORK SERVICE'.

You could also potentially solve this problem by giving NETWORK SERVICE the relevant permissions to the site collection, however I haven't tested this.

If your farm configuration as a separate account for this service (following SharePoint best practice) then this may well not be an issue for you, but I feel this is worth logging for anyone who may come accross this issue in or out of a 'stand-alone' configuration.