That GUID is probably {D61A27C1-8F53-11D0-BFA0-00A024151983}, which is the AppID for the Removable Storage Manager.
While it's true that "Backup Operators" have the "SeBackupPrivilege" privilege granted, apparently Microsoft didn't bother (at least in Windows XP Professional) to grant them explicit permission on the DCOM applications necessary to actually make running a Scheduled Task-based backup work.
You have a couple of choices. You could just give that user "Administrator" rights, and then everything will "just work".
I've also gone through the ordeal of figuring out which DCOM objects need to have their permissions changed to make this work with a user who is only a member of "Users" and "Backup Operators". To test it, using the "Component Services" management-console snap-in, navigate to "Component Services", "Computers", "My Computer", and "DCOM Config". Modify the "Launch and Activation Permissions" on each of the objects named below, changing the setting from "Use Default" to "Customize" and adding "Backup Operators" with both "Local Launch" and "Local Activation" permission to each.
- Removable Storage Manager
- Removable Storage Sink Layer
- Volume Shadow Copy Service
After changing those permissions, I found that I was able to make a backup job running as a Scheduled Task under a user context who only had "Users" and "Backup Operators" group membership funciton as I expected.
Microsoft is aware of the issue (see http://support.microsoft.com/kb/311866), but their article doesn't provide a correct resolution. (It's an April 2002 article, too... It clearly hasn't been updated for the changes to DCOM made in Windows XP SP2. http://technet.microsoft.com/en-us/library/bb457148.aspx)
DCOM permissions are stored in the registry as REG_BINARY keys. There's no mechanism that I'm aware of in stock Group Policy for manipulating them. It should be possible to replicate the LaunchPermission value (see it under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID{56BE716B-2F76-4dfa-8702-67AE10044F0B} after you change the launch permissions, for example) between different computers with a simple registry merge because the ACL we're placing on the resource only names well-known SIDs and no machine or domain-specific SIDs.
I'd just grant the user "Administrator" rights and be done with it, but there certainly is another option if you want to do it.