How about some answers:
- ACL Settings for Wordpress on IIS (link broken - see original blog post contents below)
- Windows Cache Extension for PHP
- Don't ignore caching, just use what's recommended for IIS
- The default installation settings for mySQL work fine for small to medium sized Wordpress blogs. You might look over these installation tips for a step-by-step install process.
- How to secure Wordpress admin directory on IIS is one option.
I have been running Wordpress on my IIS server for some time without any issues. Drop me a note if you have any further questions.
Original blog post contents (retrieved from http://web.archive.org/web/20100326200206/http://www.dscoduc.com/2009/11/acl-settings-for-wordpress-on-iis on 2014/11/10):
ACL Settings for WordPress on IIS
After getting my WordPress blog I wanted to ensure that my file ACL’s were configured correctly. This process is a little different than configuring BlogEngine.NET because WordPress runs using impersonation instead of a separated service account and anonymous account.
Unfortunately there was added complexity I upgraded my web server to use Windows 2008 R2 which has the latest version of IIS, version 7.0. Improvements to IIS 7.0 include a fundamental change to the way identity is managed. Specifically, IIS 7.0 uses two special accounts that didn’t exist in previous IIS versions: IUSR and IIS_IUSRS.
More information about these special accounts can be found over at IIS.NET on an article titled Understanding the Built-In User and Group Accounts in IIS 7.0.
So the goal was to configure the bare minimum level of access needed to run the blog. To assist in this effort I spent time with Sysinternals Process Monitor to watch for ACCESS DENIED messages as I browsed the blog and performed administrative tasks.
I started by removing inheritable permissions at the root folder. Next I removed all accounts except for the two core accounts that are required to manage the folder: SYSTEM and Administrators. Next I granted READ and LIST_FOLDER permissions to IUSR and IIS_IUSR at the root folder. With inherited permissions enabled by default on sub-folders this ACL would propagate down the folder tree.
If I stopped here I would be able to serve up content but would be unable to modify plugins and upload posts with attachments. I wanted all of the blog features to work so I modified the permissions of the wp-content folder by adding MODIFY access for IUSR account which grants MODIFY and WRITE access.
After the last ACL setting I checked the blog and found everything working correctly. After all was said and done I only needed to configure ACL’s in two places, the root and the wp-content folder:
UPDATE: After I wrote this post I decided to remove the write access to the /wp-content folder except when I needed to update a plug-in. Additionally I needed to grant write access to the /wp-content/uploads folder in order to support blog posts with attachments and images.
I also discovered that additional write permissions were needed at the root level whenever I wanted to perform an automated update of the WordPress core files, something I also can manually grant whenever an update is required.
In the end the only rights left on for the IUSR account is the read/list permissions for the website root (which inherits down through the site folders) and read/list/write permission on the uploads folder.