ContentDeploymentJob j = null;
j = ContentDeploymentJob.GetAllJobs()["Selected Sites"];
This works great if the user has uber access. If not the RunWithElevatedPrivileges doesn't buy you any thing as it seems to be ignored. I'm working on a workaround currently.
Apparently the content deployment object model is blocked if ran from anywhere but central administration. But, you can undo this with the following powershell.
# load sharepoint api libs
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") > $null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration") > $null
# get content web service
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
# turn off remote administration security
$contentService.RemoteAdministratorAccessDenied = $false
That said, I was unable to impersonate a Farm Admin. It seems that even when I used RunWithElevatedPrivileges or straight impersonation with SSS, it would still tell me that the user logged on was not a farm admin.
So for a work around I will be adding the user that will be managing content deployment as a farm admin temporarily so I can move on.
Also I've noticed that changes to code and security take some time and iisresets to go through. So make sure to iisreset and try it twice, I lost a lot of time debugging working code because of this.
OK looks like the user also needs the following db access:
GRANT EXECUTE ON proc_putObject TO [account]
GRANT EXECUTE ON proc_putDependency TO [account]
GRANT EXECUTE ON proc_getNewObjects TO [account]
GRANT EXECUTE ON proc_GetContextObjectEventReceivers TO [account]
GRANT SELECT ON TVF_UserData_ListItemLevelRow TO [account]
GRANT EXECUTE ON proc_UpdateListItem TO [account]
GRANT EXECUTE ON proc_UpdateItemInNameValuePair TO [account]
GRANT EXECUTE ON proc_EnsureTranLockNotRequired TO [account]
GRANT EXECUTE ON proc_UpdateDiskUsed TO [account]