Did you know that WordPress works – and works great – on Microsoft Windows? Sure, WordPress runs on top of PHP and MySQL, which are commonly thought to be related to Linux, but they work perfectly on Windows Server also. In fact, this blog post that you’re reading right now is running via WordPress on Windows, MySQL, and PHP.
Here’s a blog post by Artur at OrcsWeb showing a walk-through of installing WordPress on Windows Server.
As you can see in the post, Microsoft’s WPI (Web Platform Installer) makes it super-easy even for non-administrators.
I installed the W3 Total Cache plugin last night and enabled about 1/2 of the features. Everything seemed fine initially so I left it alone. Today I went to write a post and noticed my site was down. Yikes! No idea how long it was down because no one bothered to tell me (thanks for nothing readers! :>).
Since the last thing I changed was adding the W3TC plugin, I decided to remove that. Since I couldn’t get the site to load, I had to figure out a way to do this manually. Thankfully I stumbled across this post:
I followed the directions there (minus the .htaccess steps since I’m running on Windows/IIS versus Linux/Apache) then killed all the PHP and W3WP processes related to my site that were running. They kept popping up new ones so I stopped the app pool, then tried again and was able to kill them all. After that I restarted the app pool and hit the URL – all better! Yeah!
I think I’ll avoid that plugin now.
Today I noticed we were getting an increasing amount of spam on one of our form pages. I was curious to see if all of the user IP addresses were the same (in which case I’d just add them to the IIS7 IP Restrictions list). To quickly and easily figure this out I decided to use LogParser. Besides just querying for the page though, I wanted to add an additional condition to exclude rows that came from a certain internal IP address that we use for monitoring.
Here’s a generic version of the query I used:
LogParser.exe -q:on "SELECT * FROM x:\wwwlogs\W3SVC1\u_ex130411.log WHERE cs-uri-stem='/SomePage/' and c-ip<>'10.10.1.100' >c:\temp\PageVisitors.txt"
I wanted to see the full logged data for the request, but if I didn’t, I could have very easily just pulled the IP addresses using:
LogParser.exe -q:on "SELECT c-ip FROM x:\wwwlogs\W3SVC1\u_ex130411.log WHERE cs-uri-stem='/SomePage/' and c-ip<>'10.10.1.100' >c:\temp\PageVisitors.txt"
You can see that I’m piping the results to a text file (the “>c:\temp\PageVisitors.txt” part) so that I can easily deal with the results. You may also want to take note that I’m using the “-q:on” flag which runs the command in Quite Mode. If you don’t set this flag then LogParser will show results one page at a time. When piping to a text file rather than the command prompt window, you obviously can’t hit a key for “next page” so without this flag the query will actually hang forever if there is more than one page worth of results.
Installing Windows 2012 Server Core plus IIS8 isn’t as hard as you might think. At least it isn’t as hard as I thought!
Server Core can be intimidating to long-time Windows users who expect to see the comfortable familiarity of the Windows desktop (though that has also changed with Server 2012). Rather than a Windows desktop you are presented with a command window and required to make changes through text commands. Hey, what is this – Linux?!?
You can relax though. There are actually ways to still manage your server via GUI through the use of various remote tools. That gives the benefit of the smaller footprint and attack surface on your server, but still the ease-of-management that users are use to.
Here’s a great recent post with a few quick steps on getting Windows 2012 Server Core installed (not many steps there – its super-easy) then the command lines needed to install IIS8 and enable it for remote access. Then the few steps required to get connected remotely to manage your server.
Check it out – it’s likely way easier than you expected!
Microsoft’s IIS SMTP service won’t log usernames even when SMTP-AUTH is enabled and clients are all authenticating. So, what happens if someone starts abusing the SMTP service (or you perhaps have a runaway process performing the abuse)?
Well, it takes a little effort but it is possible to track down the username being used to authenticate to the service. Here’s a post by Jeff Graves of OrcsWeb showing exactly how to track down this information: http://jeffgraves.me/2013/01/08/linking-spam-sent-through-shared-iis-smtp-server-to-a-user/