Shaun,
The background thread for the scheduler is also spun up in Application_Start, so it get's the same identity and has the same problems. This was discovered when Tanzy tried to create a scheduled task to delete the files at a later time.

I imagine this has also caused a few people some grief when creating scheduled tasks to acess the database if their connection string is using an impersonated user.

The EventQueue was designed for performance when being used for passing messages between any events, even inter-module communication on the same page.  It wasn't designed for just this specific event.

Even if the message store is moved to the Database, then the EventQueueController would most likely still have problems deleting from the database on Application_Start when the environment is setup this way.

Aren't you at the ASPInsiders conference? Maybe you can get some attention from someone at Redmond as to when the impersonated user identity actually gets switched over, and/or what they would suggest for an environment setup like this.

Hmmm...  I am rather new to DNN and I am struggling with this EventQueue problem you are discussing here.

I am rather confused. What can I do.
I have tried to change identity :: impersonate to false in web.config. But that failed because this setting is not allowed by the server host.

What if I delete all the "Application_Start--xxxxxx" files in the EventQueue folder. Will that solve my problem?

Is the only solution to use DNN 3.2 (and .Net 1.1) or a completely different CMS? 

Looking forward to get wiser.

Cheers,
Magnus