WordPress on IIS without the 404s, permission errors and expiring certificates

The five things that go wrong

• Pretty permalinks return 404. WordPress writes rewrite rules to .htaccess, which IIS ignores. Without the equivalent URL Rewrite rules in web.config, every page but the home page is missing.
• Updates and uploads fail. "Installation failed: could not create directory" means the application pool identity cannot write where WordPress needs to. The usual fix on forums, giving Everyone full control, is how sites get compromised.
• PHP will not start. "FastCGI process exited unexpectedly" on the first load is a missing Visual C++ runtime, and the next surprise is a php.ini with upload and memory limits far below what a theme installer needs.
• The database is wide open. A default MySQL install listens on every interface, root has a blank or shared password, and WordPress is pointed at root because it was quickest.
• SSL is a yearly chore. A certificate bought, installed by hand, and forgotten until the browser warns visitors away.

None of these is hard for a specialist. All of them are easy to get wrong when you are doing it once, from a search result, on a Friday afternoon.

One click installs WordPress, already locked down

The add-website form has a checkbox: Install WordPress (latest) into this site. Tick it and ServerMaid does what a specialist would do for a WordPress install on Windows Server, in order:

1. Downloads the current WordPress release straight from wordpress.org and checks it against wordpress.org's own checksum before unpacking it into the site.
2. Writes wp-config.php connected to the site's own database and database user; that user can reach only its own database.
3. Generates the security salts and keys locally, unique to this site, rather than copying them from a web page.
4. Sets pretty permalinks, with the IIS URL Rewrite rules WordPress needs already in place.
5. Hands over: you open the site in a browser and choose the admin user and password. Nothing is chosen for you.

The same install is available from the command line with the --wordpress switch. It needs the WordPress module (included in every Agency licence), which works inside the Websites and SSL module.

The hardening applied to every install

• The theme and plugin file editor in the dashboard is switched off (DISALLOW_FILE_EDIT), so a stolen admin login cannot edit PHP on the server.
• WordPress minor security releases install themselves.
• Admin pages are forced over HTTPS when the site has its certificate.
• Debug output is off and unfiltered HTML is off.
• PHP cannot run from the uploads folder: a named URL Rewrite rule in the site's web.config returns 403 for any .php file under wp-content/uploads, which closes the most common route for a malicious upload.
• Direct requests to wp-config.php, xmlrpc.php, readme.html, license.txt and any .git or .svn folder are refused.
• wp-config.php is read-only for the website's own application-pool identity.
• The sample Hello Dolly plugin is not installed.
• ServerMaid checks that Users, Everyone and Authenticated Users have no rights on the site folder.

What is still yours to do

Third-party plugins and themes remain your responsibility, on any host. Install them only from wordpress.org, keep them updated (a staging copy is the safe place to try an update first), and delete anything you are not using rather than leaving it deactivated. ServerMaid does not scan plugin code; it makes sure a bad plugin has as little to work with as possible.

Moving an existing WordPress site over

Add the website in ServerMaid first, with its domain and www hostname. That creates the folders, application pool, rewrite rules, database and account. Copy your WordPress files into the site's wwwroot, import your database dump into the new schema, and put the credentials from the site's private folder into wp-config.php. Point the domain at the server, press Repair, and the certificate is issued as soon as the DNS check passes. The old site keeps serving until you move the DNS, so there is no gap.