Lee, the answer doesn't seem to be that simple. For PST files to get transferred to server (or even show up in console list) for migration, the PST migrator task has to be running (Please correct if I'm wrong, but that's what I just observed in lab). That is running, not processing. As you say, processing can set to happen once a week, or, even better, manually.
The problem is, that on the admin console, when files have been transferred to server, you can do absolutely nothing for file in the list on console. All options are grayed out. When you right click the file, and choose delete, you just get an error message, that states it can't be deleted.
As far as I understand, at this point the only option would be to trace the actual file name on PST holding or temporary area and delete that file - I'm not sure what happens then, or can it even be done. I am quite convinced that first level admins can not be tasked to do that.
I don't know if I'm missing something completely, but these observations I've done in my test lab. I am looking for same kind of possibilities you have with server driven migration, where you have the possibility to prevent migration before manually confirmed.
As a reminder, I am looking for way to confirm migrations manually, because Symantec support has confirmed there is a possibility to migrate PSTs to wrong archives with even temporarily shared computers (We cannot guarantee that nobody would log on to colleague's workstation even once).
