Troubleshooting WordPress Automatic Updates on IIS 6

WordPress automatic updates are awesome. When they work, they’re as easy as a click of a button. When they fail, however, you’re left either reconciling yourself to an eternity of manual updates, or troubleshooting your host–a process that routinely takes much longer than applying the update manually would’ve.

In this case, my VPS was running IIS 6 and the updates weren’t working. First, the update screen would merely say it was downloading the new version, and it would never make any progress. Then, when I extended PHP’s max_execution_time, I encountered a FastCGI internal error saying the process exceeded the configured activity timeout. When I corrected that, WordPress reported permissions errors while trying to move the new files into place. My full solution was as follows:

Backup Everything

Any time I’m updating anything; download a full & current copy of the site, and export all tables from the database.

Fix the FastCGI Timeout

Open WINDOWSsystem32inetsrvfcgiext.ini, and, in the section labelled PHP, add ActivityTimeout = X, where X is the desired number of seconds after which to terminate an unresponsive script. Restart IIS.

Fix Permissions

Much like how apache is often configured to run as “nobody” in order to prevent malicious scripts from modifying files, IIS (by default) runs as a user named IUSR_[hostname], where [hostname] will be a string you set up when initially configuring your site. Unlike apache, however, on IIS, 777 permissions don’t necessarily mean any user is permitted to write to a given file or directory.

To fix the problem I had to open up my web root in IIS, and give my IUSR_[hostname] full permissions. I was then able to run the update, after which for security purposes I reduced that users permissions to the original level.