Wordpress Theme Upload error on IIS 7: AppPoolIdentity, FastCGI Impersonation and What not?

After hearing from like a zillion people I finally set out to try WordPress today on my Windows 7 PC. Initial reaction towards the app was cool. Small, sweet download. Pretty easy to run if you already have the pre-requistes like IIS, PHP and MySql up and running. Well during my "Lets see what it's got" phase with WordPress I was checking out some cool themes that are available for free. Selected a few of them and wanted to try them out. A cool feature in WordPress allows you to upload themes in zip packages. Further it automatically reads, uploads, configures the theme and makes it available for you to use. So far so good.

While I was uploading the ZIP package, I recieved the following message:

Unable to create directory "File Path of Upload diretory". Is its parent directory writable by the server?

I gave appropriate write access to my App Pool identity and then gave it a shot. No Go. I quickly Binged a bit for the error and found a lot of articles which seem to be Linux\Apache favouring. Things like "give 755 permission on the directory" or "give 777 permission on the directory". Well I had already figured out that I needed to give permission. My question was to which user?

Being in a Support environment, a lesson I learned was never to let go off basics. Enter Process Monitor. :)

Here's what I did:

1.) The 1st thing I did after firing up ProcMon was to include a filter for w3wp.exe and php-cgi.exe because I was sure these were the only relevant processes for my problem.
2.) Ran and captured File access parameters in ProcMon for the above 2 processes.
3.) Once it was captured, I needed to find the Access Denied result. Knew it would be there somewhere. Here's how it looked like.

Now, if you notice I was getting an Access Denied for the uploads folder creation operation. The last column, however, states that the user associated to this operation was my AppPoolidentity-->blog. But I had given the acess already. Couldnt figure out why it was failing.
4.) While thinking about this, I hovered on the details column in Procmon. This was my saviour. Check it out...

As you can see it says that php-cgi.exe was impersonating IUSR account for the write operation in this case. As soon as I gave write access to IUSR on the wp-content directory everything started to run smooth.

But what I really wanted to know was - Why is IUSR account coming into all this?
Answer: Time to go back to basics :)

When I noticed the process name once again, that is when it hit me. My machine is running PHP with Fast CGI and I have the following setting in my php.ini:

fastcgi.impersonate=1

Which esentially means when fastcgi impersonation is enabled, PHP will perform all file system operations with the user id that is currently authenticated by IIS. In my case I was using Anonymous Authentication with default settings. Hence IUSR. 

Case Solved. Having fun with WordPress. All is well. Now, something off-topic but IIS related. Once the file directory was created and all that I found this cool thing in the following pic:

As soon as a directory is made from WordPress, IIS (w3wp.exe) performs a NotifyChangeDirectory operation for the root and the parent directory. In this case notifying not just the AppPool for this application but all the AppPools in the website. Cool.

Hope this helps. Have Fun!