Anyone brave/stupid/stubborn (delete as applicable) enough to dare to run Wordpress on Windows and IIS, is likely to have run headlong into the brick wall that is NTFS file permissions.

The language I'm using here is deliberately ironic. Even in 2016 the level of help you can expect when searching online for Wordpress / IIS configurations is abysmal. The attitude of a great many contributors amounts to the following:

"Why are you using Windows (you idiot)? Don't use that, use LAMP (DUH!) and don't come around here no more, asking your Windozy questions like a n00b... it's called CHMOD, now get back in your damned cage."

The Wordpress docs aren't a great deal better.

So perioically I find myself running into this issue on a Wordpres IIS installation, whereby I'm unable to update plugins or do other things that involve the system putting files into the wp-content folder. Thus ensues the usual frustration of spending hours Googling, clicking on results that look like they might be helpful, only to find that they're for a LAMP stack.

No. More. Damnit!

So I thought I'd document the various things I've found myself trying. Some of these have worked on their own in certain environments, others required a combination of factors.

Check your file permissions.

It's the first place you look when you see a filesystem related error. Check who owns the wp-content folder in Windows. Check who has access to write to this and sub folders.

Many times, this is the only advice you'll be able to find that is Windows centric, and indeed it is very important.
Messages are conflicting, however.

There are various users that could require access to this folder, depending on your setup.
It used to be the case that people would grant access to the NETWORK_SERVICE user. This is outdated advice and while it may help, it's not the best security wise.
Generally these days I would advocate using the App pool user for the site in question.
If your Application pool for the site is set to the default ApplicationIdentity, then you would want to grant write access to the wp-content folder to the user:
IIS APPPOOL/YourAppPoolName - where YourAppPoolName is the name of the website in IIS.

Other advice states that granting write access to the IIS_USRS group will help you - indeed, it might. This group is supposed to house the application pools, but it's overkill to grant access to all your IIS users if you have multiple sites.

Another account to try is the IUSR account, which is the anonymous IIS user. Indeed, in many cases you'll find that PHP is running as this user and thus it would make sense that it should have access to folders it wants to write.
In my case, only the Application pool user is necessary, but your mileage may vary.

While this is always the first place to look, it's not always the solution for Wordpress plugin update issues. A good test is to temporarily enable full control over the wp-content folder for 'Everyone'.
Please note that I am not in any way advising you do this permanently!
The idea is that if you enable full control for everyone and still have a problem, it's likely not permissions causing your issue.

Procmon is your friend...

As a Wordpress user on Windows, friends are few and far between! (It's ok, I'll be your friend too).
Procmon is a lovely piece of software that gives an incredible amount of realtime information and will allow you to get an idea of what's happening and to which files, when Wordpress is attempting an auto update or plugin update.
Procmon can be downloaded directly from Microsoft.

It can be a little overwhelming, but using filters you can drill down to see which files are being accessed, and by whom.
A good starting point is to add a filter for the .maintenence file in the root of your Wordpress installation. This file is added temporarily by Wordpress when it's attempting an auto update, and catching it in Procmon will help you to see what user Wordpress is using to write the file.

The temporary upload folder

When PHP is uploading files from forms and such, and indeed when Wordpress is downloading update packages, it tends to store them temporarily in a folder while they're being transferred. By default in many Windows PHP installations, this folder is C:\Windows\Temp.
Obviously this is a standard temporary folder and is shared with countless other processes.

In the first case, this folder might not be fully writable by PHP - but it makes sense to change the folder completely, just to segregate these operations from the rest of your OS.

In the php.ini file (If you've used the Windows Platform installer you can access this via the PHP Manager in IIS, otherwise you'll usually find it in C:\Program Files (x86)\php or similar.) there's a setting that you can change to whatever folder you like:
upload_tmp_dir = "C:\YourNewPHPTMPFolder"
Be sure to give writable permissions to PHP on this folder. Again, check what user PHP is running as!

Disabled functions

Another thing that can really trip you up, is spending all your time looking at file permissions without realising that PHP may not even have the ability to copy files from one place to another!

Once again in the php.ini file you may find a setting for disable_functions. Newer versions of the Web Platform Installer are able to lock down PHP pretty tightly and disable a whole bunch of functions out of the box, including some file operations that are used by Wordpress when updating plugins.
Remove the following functions from your configuration to re-enable this functionality:
move_uploaded_file chdir mkdir rmdir rename

WinCache

WinCache is a popular caching module for PHP. Some versions of the module have been known to cause problems with Wordpress automatic plugin updates on IIS. There's an article about this here: http://ruslany.net/2011/04/wincache-and-wordpress-plugin-upgrade-problem/
Essentially the advice is to update the version of WinCache, but you could simply try disabling it to see if it is indeed the cause of your issue.

YMMV!

These are the main issues I've found when attempting to solve the file permissions problems that plague many Windows IIS Wordpress installations. There may well be more, and I'd be very interested to hear them!