While at a client, i stumbled upon this problem. I'm going to share the woes and how it was solved in case anybody else runs in to it.
So the problem was evidenced by a client (full dcom) failure to manually archive an item. Automatic archiving worked, syncs, enables...the whole shebang. I guess it goes without saying that you shouldn't think the gig is in the bag until the checklist is all done. :) The eventlogs were quite mysterious, claiming only a warning that said something akin to the archive attempt exceeded it's queue and was discarded. End result? A pending email sitting in a mailbox.
So okay, at first I didn't know what to do with this. After all, the client not being able to archive and the server being able to do so without an actual error is pretty weird. So first thing I do is check the VSA acct and perms...and everything looks great, even down to the mailstore. Resetting the VSA via the admin console yielded no joy. Next we're checking msmq because i'm guessing that maybe the clients are missing the perms to open connections...that all looks good. For good measure we uninstall/reinstall msmq (including moving the storage locations), kill the queues and recreate them,...even kill the task and exchange target. Still no love. Preperations for a long haul begin.
After many dtraces, it's assumed that this error is one of our favorite, "Unexpected error" type events. And that's when we all knew we were in deep. So okay, being logical we switch the self installing features on and try a pure http connection from the client (since apparently working on the server first yielded no joy). Guess what...this works. So now I'm trying to figure out what went wrong on the dcom side of the house. Every EV process now gets an inspection and addition of rights. Everything looks solid, switch back to the full client and no joy.
Long story short, we solved this problem by deleting the VSA account, and creating another VSA with the exact same permissions. Now it works just fine. I guess sometimes the problem really is the first thing you tried. But I thought I'd mention the experience to demonstrate that you can't trust ADUC to give you the real permissions it's actually got deep in the AD structure.
I omitted 2 hrs of troubleshooting where I was doing shameless things with the SQL tables and such in order to make mapi work...but that's neither here nor there.
I guess some days it just comes down to voodoo. :)
micah, sharin' pain
