I'd like to throw my 2 cents in on this issue.  I have been working on a site where the client specifically requested DNN.  We use a shared platform, and for security reasons, sites cannot access the windows directory. 

This issue is likely being causes because DNN is, for unknown reasons, attempting to use the temp directory on the windows drive that IIS was installed on.  The DNN teams 'solution' for this problem is to simply run the processes under Network Service, and the problem will go away.  This is not a solution to the problem.  Shared hosting environments that require at least basic security cannot allow multiple sites to perform file i/o to any shared location on the drive.  

I have attempted to run the install package, which generated errors at 05.01.00.  I then noticed that it was attempting to load '.cs' files from that temp dir, so i wondered if a compiled install of DNN might combat this problem, but no longer needing to use as much of the JIT with cached versions of semi-compiled code-behind pages.  

I  compiled the install package, which i must add did not even include the entire working DNN installation (i had to go and fetch the dotnetnuke.modules.html.dll from the Deployment zip and add it to my install distro to even get it to compile successfully) and then i ran into the issue outlined in this thread.  It's looking like i'm going to have to tell my customer that there is no way to run DNN on a shared hosting platform that needs basic security in place.  I have yet to find anybody who can offer anything on this problem other than to simply 'turn off security' and run as NS.  This is perfectly acceptable for a stand-alone IIS configuration, but for shared platforms this is not acceptable.  I'm hoping there will be a workaround for this, because i'd like to make my client happy and give them the CMS that they desire, which in this case is DNN 5.x.

For posterity, my previous comments on a related thread can be found here.