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.
Restore the System State portion of the backup on another machine running W2K3 or Windows XP, choosing the "Single Folder" option for the "Restore files to" and picking some sensible "Alternate location" (like a directory you make for that purpose). You'll be warned about how this is an "advanced" feature and that not all files will be restore. For your purposes, that's fine.
You'll get back a lot of the "%SystemRoot%\System32" directory (a lot of DLL files, etc), and the registry, too.
From there, the instructions that Shial (who seems to look rather like SHODAN) posted are the right track. Fire up "REGEDIT", highlight "HKEY_LOCAL_MACHINE" in your local registry, then use the "File / Load hive..." option. Choose the file from the "Alternate location" corresponding to the part of the registry you want to extract data out of (these files have no extension):
- SYSTEM - HKEY_LOCAL_MACHINE\System
- SOFTWARE - HKEY_LOCAL_MACHINE\Software
- SECURITY - HKEY_LOCAL_MACHINE\Security
- SAM - HKEY_LOCAL_MACHINE\SAM
- DEFAULT - HKEY_USERS.Default
Choose any name you want when loading the hive, so long as it isn't a name that's already used under HKEY_LOCAL_MACHINE. You're "mounting" that hive into your live registry, not unlike mounting an NTFS volume under a directory (except that you don't have to make the registry key to mount the hive into like you would an NTFS mount point).
When you're done, unload the hive by highlighting the key where it's mounted (HKEY_LOCAL_MACHINE\whatever_name_you_chose) and doing a "File / Unload hive...".
Best Answer
Nope, those old backups backed up the store in its entirety, it didn't do mailbox level backups. So the only way you can do what you want is to restore the backup to a temporary [virtual] server, then export the mailbox from that server.