JimmyLi.net

Note: This article is Part 4 of the IIS Tutorial Series. Although this article does not relate to IIS, IIS is probably the primary web server the user reading this article is using.

Running a re-occurring task on a web server on a periodic basis without interaction from the client is sometimes necessary. Such as to send a daily notification email, or run a statistic processor. UNIX-like Operating Systems have the well-known Cron as a simple option. On Windows, it’s Task Scheduler. In this tutorial, I will step through the process of setting up a scheduled task to have a web script executed periodically. It’s also important that you have a Windows User login with a password that the task can execute under. For this tutorial, here’s an overview of how the task execution process will work:

1. A task scheduler is set up to run once every day.
2. The task is to execute a batch file, which is simply a text file containing a list of commands.
3. A command in the batch file is to call Wget, a program that retrieves content from web servers (like a web browser), and tell it to call the URL of your web script.

Note: You might be thinking why we are calling the web script through a publically-accessible URL rather than a local system path, and the reason is to keep this tutorial simple. Calling a local path requires calling the PHP interpreter, which is a bit more complicated. There are also the problem of the current execution path of the script, which may require adjustments to any relative paths you use in your script (such as include() calls). So in this tutorial, we’ll execute a publically accessible URL, and let the web server take care of the rest.

Note 2: We could just have the Task Scheduler execute Wget directly without the batch file, but I’ve added it because the batch file can contain more than one command we can execute. However, in this tutorial we will only execute one command.

Creating a script to execute periodically
We’ll keep this very simple, and create a script that we can see results . Create the following PHP script.

mail('[email protected]', 'My Subject', 'Hello World!');

Replace the email address with your own. Save the file as helloworld.php. This will just send out an email to your email address with “Hello World” as the content. Put the file on your web server so that you can access it through a publically available URL. For example: http://test.com/helloworld.php

Install Wget For Windows
Wget is the program that will call the URL (which the web server will execute). Download it, and install it on your web server. To make it easier to execute Wget in the batch file without requiring the full path to the Wget executable, add Wget to the path of your system. For more information on how to do that, visit this page on How to set a path in Windows. (Even if you’re not using Windows 2000/XP, most Windows version applies.) Add the Wget program directory’s “bin” folder, which for most default install is: C:\Program Files\GnuWin32\bin

Setting up the batch file
Create a batch file and name it run.bat. Save it to a location on you web server that is not in a public path. For example (to keep it very simple): C:/scripts/run.bat

Open up the batch file and add the following, where test.com is your domain name.

wget -q -O nul http://test.com/helloworld.php

This basically tells Wget to call that URL (to your script), and don’t output anything nor save to a file.

Setting up task scheduler
Add a new scheduled task by going to Scheduled Tasks on your web server. It should be located in the Control Panel. Double-click on Add Scheduled Task. Continue until it asks you to browse for a program to execute. Click on “Browse…” and look for and select the run.bat file you created. Continue with the options, enter a name for you task, and select to perform the task Daily, and set the time to 10 minutes from the current time. Continuing on, it will ask for a Windows username and password the task will execute under. After that, you’ll reach the end, and that’s it! You can also opt to view more advance options. With the advanced options, you can even set multiple schedule times under the single task. For example, you want it to run the task once an hour between 8am to 5pm, but only once every four hours thereafter. If you haven’t changed the advanced options, wait around 10 minutes, and your script should execute. The main screen of the Scheduled Tasks will also display when the last execution time was.

Now, all that’s left is to turn that script into something useful. The script is like any normal web script and it can do anything you can make it do, such as checking a database for deadlines occurring within one day, and sending out email reminders, etc. Since the URL to the script is public, you might want to add some kind of hard-to-guess preset token to the query string of your URL, and your script checks that it’s a match before executing it.

Note: This article is Part 3 of the IIS Tutorial Series.

URL Rewriting is a powerful functionality that provides you the ability to modify your URL’s appearance. If you’re reading this, you probably know what a rewritten URL is so I won’t go into examples. URL Rewrite has became so common due to its benefits of the relevance of the URL to its page content for Search Engine Optimization (SEO) and for link sharing (e.g. social media), many Content Management Systems (CMS), such as WordPress, and programming frameworks already provide out-of-the-box ability to transform ugly URLs to “pretty URLs”. That is, on the front-end. However, the web server cannot understand the pretty URLs to send the results properly back to the web application. That is what a URL Rewrite module is for. It converts transparently the pretty URLs back to the ugly URL so the web server can send the data properly back to the application.

For those who’ve worked with Apache, almost all types of modules for your needs are readily available, easily to download if necessary, and a plentiful of documentation available. Fortunately, for IIS 7.0 or later users, Microsoft does provide a URL Rewrite Module (which I won’t go into here). Unfortunately, for users of IIS 6.0, we have to resort to third-party modules to provide URL Rewrite functionality. Although there are a few of them that are easy to find, most of them are not free, or they provide a free limited version, such as only a limited number of URL rewrites per day, or rewrite rules that are active for the whole server, and not for individual websites. In this tutorial, I’ll introduce a free and powerful URL Rewriter, and step through the installation and basic setup.

Download and Installation
Iconics ISAPI Rewrite Filter (IIRF) is a free ISAPI Rewrite filter that works on IIS 6.0 or later. It can be set up to be used similar to Apache’s .htaccess rules so that rules applies only to a specific website, or even a single directory. The rewrite rules are also very similar to, if not exact, Apache’s rewrite rules. To begin, visit the IIRF website and download the ZIP file (version 2.0, at this time of writing).

Installing is as simple as unzipping the file, and placing the folder in the root of your server’s hard drive (e.g. C:\IIRF\). That’s it! IIRF is installed!

Website Setup
To set up an IIS website to use IIRF, open up your IIS Manager, select your website, right-click and select “Properties”. Click on the ISAPI Filters Tab at the top.

On the left, click on “Add…” to add a new filter. Use a name that is easy for you to understand. Here, I used “ISAPI Rewrite” as the Filter Name. For the Executable, browse to the DLL of your IIRF installation. It should be in the “bin” folder (e.g. C:\IIRF\bin\IIRF.dll).

Hit “OK” to save your settings, and “OK” again to save and exit properties. Just like that, your website should be enabled to use IIRF. You’ll have to do this for each website on the server that you want to use URL Rewrite for.

Adding Rewrite Rules
This is very similar to Apache’s .htaccess rules. The rules for IIRF are so similar, pretty much any rules that I find online for .htaccess I can use for IIRF, and it works fine. To add rules, create a file called IIRF.ini in the directory you want to use the rewrite on. For most of us, that should be the root public directory of the website.

To do a quick check on whether IIRF is set up properly, edit the IIRF.ini file and add the following line:

StatusUrl /iirfStatus RemoteOk

This will load a status page at the /iirfStatus directory of your URL. You’ll also need to be sure you have a host name or URL mapped to your website to test this. For example, if your website is at test.com, visit http://test.com/iirfStatus to see the status of IIRF. If a status page loads that is similar to the image below, IIRF is working properly for the website. (You’ll probably want to remove this StatusURL line before production.)

That’s it! URL Rewrite should be enabled for your website. For a list of rules and logging options, there should be a help guide in the IIRF installation folder: /AdminGuide/Help/IirfGuide.chm
An online documentation version is also available. If you need help, the discussion forum is also fairly active and useful.

Despite my lack of updates, I’ve noticed based on search query logs of visitors arriving on this website, a lot of them are regarding installing PHP 5.3 on IIS. Due to the fact that you can no longer use ISAPI with PHP 5.3, I’ve had the same frustrating experience as others when I was trying to upgrade from PHP 5.2 to 5.3. I did a lot of research on it, and resources were few, so I decided to write about it once I’ve successfully was able to upgrade.

Due to the demand of IIS usage there, and resources are few and scatter, I’ve decided to start an IIS Tutorial Series, beginning with Part 1: Installing FastCGI and PHP for IIS 6.0. I hope this is able to help a lot of those who are using IIS, especially with PHP. Over time, I will be adding more tutorials. My experience as a web developer mainly began with using Apache, but eventually having to use IIS at my workplace, I’ve found that a lot of the convenience features with Apache were not available (or easily available) in IIS, so I want to be able to create more tutorials on being able to use such features on IIS.

Note: This article is Part 2 of the IIS Tutorial Series.

Starting with a little history, before PHP 5.3, the options of getting PHP to talk to a Microsoft SQL Database Server was either using a generic database connector, such as ODBC, or PHP’s included MSSQL connector extension. The MSSQL extension was nice compared to ODBC as you didn’t have to set up a separate object (the ODBC connection object) to talk to the SQL Server. The MSSQL extension is very similar to PHP’s popular MySQL Extension as there are functions solely for that database type. Disappointingly, beginning from PHP 5.3, that MSSQL has been deprecated and no longer included with the PHP package, as it was stated to be unstable and unofficially supported (as well as maintenance stopped a long time ago). Initially, people started re-compiling PHP 5.3 on their own with the old MSSQL to get the functionality back, but like for the most of us, re-compiling PHP is not something we would want to step into.

Fortunately, Microsoft stepped up their game and finally started to support more open-source projects such as PHP, and created an official driver to talk to their SQL Server with PHP. In this tutorial, I will go over how to install the SQL Server Driver, and connect to an SQL Server with PHP. This tutorial is applicable for SQL Server 2000 or later, using PHP versions 5.2.4 or later.

Note: You’ll need to have PHP installed on the IIS Server. If not, read Part 1 of the tutorial series on how to do so.

First, visit Microsoft’s page to download the SQL Server Driver for PHP. As of this writing, the driver is currently version 2.0. If your SQL Server is installed remotely (not on the same server as the IIS server), you’ll need to download the Microsoft SQL Server 2008 Native Client at Microsoft’s SQL Server 2008 Feature Pack site. If the SQL Server is on the same server, then you’ll already have the necessary Native Client library installed, and you can skip the following step. There are a lot of packages on that page. To quickly locate the right one, scroll down until you find a section “Microsoft SQL Server 2008 Native Client”, or you can use your web browser’s page search functionality to jump to it immediately. Download MSI package appropriate for your server.

If you had to download the SQL Server Native Client, run that executable to install it first. Then, execute the downloaded file for the SQL Server Driver. This will just do a self-extract to a folder. Save the extracted folder anywhere you want. In the folder will be a set of DLLs. Choose the DLL that is appropriate for the PHP package you are using. For more information on which DLL to use, look at the readme that’s also included in the folder. Copy that DLL and paste it into the “ext” directory of your PHP folder (e.g. C:\php\ext\). This adds the extension for PHP to use, and contains the SQL Server API functions you use in your code. This extension talks to the Native Client, which is the interface to the SQL Server.

Next, open up the php.ini in your PHP installation folder, and enable that extension. There should be a section with many lines of:
extension=xxxxxxxxx.dll

Add a new line that is specific for the DLL you are using. e.g. extension=php_sqlsrv_53_nts_vc9.dll

Restart the IIS Server for all the settings to take effect. To check that the extensions is working, create a PHP script on your website with phpinfo and the section for the “sqlsrv” extension should be in there somewhere.

That should be it for the installation. In the folder for the SQL Server driver should also be a file named SQLSRV20_Help.chm, which is a help file that includes the API documentation of the driver. There is an online version of the documentation as well.

For example, to connect to a SQL Server database with PHP, you can use something similar to the following code:

$connectionInfo = array('UID'=>'Username', 'PWD'=>'password', 'Database'=>'Northwind');
$conn = sqlsrv_connect('MY-DBSERVER', $connectionInfo);
if ($conn === false) die( print_r( sqlsrv_errors() ) );

Note: This code applies to authenticating as a SQL Server user, and not a Windows Authentication user. I have not gotten successful connection as a Windows user. If anyone knows how, please leave a comment.

Note: This article is Part 1 of the IIS Tutorial Series.

Despite IIS 7.5 being the current stable IIS release, it is only available for servers running Windows Server 2008. However for the many of us who are still running Windows Server 2003 or Windows XP, IIS 6.0 is our only option. And many of us are still limited to that option.

In this tutorial I will be doing a walkthrough on installing FastCGI and PHP. For those who are a bit new to PHP on IIS, here’s a general view of what happens when a PHP page is call through the client’s web browser:
When the client requests a PHP resource (.php), IIS responds by calling FastCGI. FastCGI is the interface to CGI Programs (in this case, PHP), so the web server can focus on web page requests. FastCGI is then responsible for calling the PHP executable to execute the PHP script, and return its response back to IIS. IIS then returns that response back to the client.

Installing FastCGI
With the stable release of PHP 5.3 out for a while now, the only way to install PHP 5.3 on IIS is through a CGI Handler. PHP 5.2 and earlier allowed us to run PHP using ISAPI, but that option has been deprecated. For those of us intending to move forward, we would have to use CGI from now on.  We’ll go over installing the FastCGI handler on IIS 6.0.

You can download FastCGI for IIS 6.0 here (version 1.5 as of this time).

Run the executable on the web server to install FastCGI. You may have to restart your machine for the installation to complete. When that’s done, open up IIS Manager and view the list of Web Service Extensions on the server tree. There should be a “FastCGI Handler” extension in the list. Make sure its status is set to Allowed. And that’s it. FastCGI is installed!

Installing PHP
Download the latest version of PHP for Windows here.
We’ll be doing the manual method of installation, so download the ZIP version and which is Non Thread Safe. It’s completely up to you whether you want to use the PHP 5.2 series or the PHP 5.3 series. Some applications may work on PHP 5.2 but not 5.3. Either one, the installation process is the same.

Unzip the content to somewhere on your server. I prefer the base of the C drive: C:\php\
Rename the “php.ini-recommended” (or “php.ini-production” or “php.ini-development”, depending on the version of PHP) file to the name “php.ini” and make any adjustments to that configuration file. (I won’t go over that in this tutorial.) You can do this at a later time if you wish. Just like that, PHP is technically “installed” on your server.

Making PHP work
Now, it’s time to make IIS understand what to do with requests that have the .php extension. When IIS hear a .php file called, we want it to let FastCGI know, so FastCGI can call PHP. To do so, we’ll have to set up the extension mapping for .php. Open up IIS Manager again and navigate to “Web Sites”. Right-click on it and select “Properties”. Select the “Home Directory” tab, and within it, select “Configuration…” A new window pops up with a listing of Application Extensions.

Look for the .php extension and “Edit…” it. If it doesn’t exist, “Add…” the extension. A new windows pops up. For Executable, look for the FastCGI library. For most default installs, it should be under: C:\WINDOWS\system32\inetsrv\fcgiext.dll
For Verbs, limit it to: GET,POST,HEAD
Save all options.

IIS can request the FastCGI Executable when a .php resource is requested. Now, it’s time for FastCGI to talk to PHP by modifying FastCGI’s configuration file. For default installs, the config file should be located at: C:\WINDOWS\system32\inetsrv\fcgiext.ini
Open it in a text editor and add the following at the bottom:

[Types]
php=PHP

[PHP]
ExePath=c:\php\php-cgi.exe

The Types is the extensions it’s listening to and the corresponding configuration it will use. So here a “php” extention will use the [PHP] configuration. The [PHP] configuration has the path to PHP’s CGI executable. This is how FastCGI knows where to find PHP. Modify the path to where PHP is located on your server.
There are more options you can add, but this should get you going.

Testing the Installation
Test that the installation went successfully. Restart IIS and create a website hosting a PHP file and output phpinfo(). If everything went well, you should see the PHP Info page with hints of FastCGI being used in there.

Note: When I was doing this, I’ve also experienced a FastCGI error during this last step stating that “Access is denied”. I’m not sure if this is common, but I was able to fix the issue by adjusting the security permissions on the PHP installation folder. I make sure that the users: Administrators, NETWORK SERVICE and SYSTEM are listed. If not, add them, restart IIS, and try to load the PHP page again.

Yahoo! Developer Network (YDN) posted an interesting blog article about thinking of bandwidth in terms of packets.  Since all HTTP data essentially travel through the Internet by packets (using TCP/IP), it’s interesting to be more aware of how much data each packet stores.  I don’t know very much in-depth about TCP/IP but it seems like a packet is typically 1460 bytes maximum according to the YDN blog article.

Although trying to optimize your website to use the fewest packets as possible sound absurd, there are actually some areas where doing it may have some small benefits.  For example, small requests that can fall in the 1 or 2 packet segments.  I’m mainly taking about AJAX (XMLHttpRequest) requests, which we expect the response to be fairly instantaneous.  Every packet sent with TCP/IP has to be acknowledged by the other server and the client has to wait for that acknowledgment, so it is typically slow (more latency) compared to other protocols (such as UDP, which is along the lines of fire-and-forget).  Since AJAX requests are typically very small, it is a good area to try to improve it by trying it as small as possible.  This includes its HTTP Header data (cookies, user-agent strings, accept strings, referrers, etc.) and any Body data (POST data).  Most of that data is fairly hard to change since it’s provided by the browser, but others such as the cookie data and POST data the web developers can.  For me, I try to keep the cookie data as small as possible.  Some web frameworks allow you to store encrypted session data in the user’s cookie by default (such as KohanaPHP), which is nice in keeping that data with the user, but it adds that extra data to every request (including non-AJAX requests).  (Though one can argue that accessing the file system or database for the session data could be slower than the extra packet.)  Instead, it maybe recommended to just store the session ID in the browser (which is PHP’s default behavior).

The blog article also has an interesting link to another interesting article measuring that XMLHttpRequest uses 2 packets to send POST data (for most browsers).  You should give that one a read.  Although I don’t have websites with huge user-bases that could definitely take advantage of these techniques, it is interesting to know what is going on when the request leaves your web browser and how to optimize it such a minute scale.

Update: I’ve started an IIS Tutorial Series on Talking to SQL Server with PHP on IIS which contains more details of this installation.

It’s been a while since I’ve touched on the issue of having PHP 5.3 talk to a MS SQL Server on IIS (without using ODBC or other connection methods).  Last time I’ve mentioned that Microsoft has an official SQL Server Driver (v1.0) for PHP to talk to a SQL Server only to find that it doesn’t work for PHP pre-v5.3, which, we didn’t really need anyway because PHP already came with a MS SQL Library driver (which was removed from 5.3) that somewhat works.

However, after starting to play around with PHP 5.3 with SQL Server again I’ve noticed that Microsoft finally release v1.1 of the SQL Server Driver, one that was stated to work with PHP 5.3 on IIS. Lo and behold, I was finally able to get it to work.  Even better, the package also came with an offline documentation on installing the driver and the whole API Reference.  Very nice.  For those who are interested, here is the documentation online, the lo-bandwidth version (no MS Frames):
SQL Server Driver v1.1 for PHP

Note that if your SQL Server is on another server from the PHP server, you’ll also need to install the SQL Native Client data access library on the PHP server.  (If it is on the same server, the installation of SQL Server already installs this package.)  It is highly recommended to use the latest version that works with SQL Server 2008.  It took me a while to find it (the 2005 version link is rampantly posted everyhere), but you can find it officially here:
Microsoft SQL Server 2008 Feature Pack, August 2008

Near the bottom of the page you’ll find “Microsoft SQL Server 2008 Native Client”.  Get the one that’s appropriate for your machine.  Despite it saying 2008, it should be backwards compatible with earlier versions of SQL Server.  I’ve tried it as far as SQL Server 2000 (on IIS 6.0) and was able to connect and query successfully (I haven’t tested for limitations and such, if any.)

And there you have it.  The official method to talk to a MS SQL Server on IIS with PHP 5.3, straight from Microsoft themselves.

Updated: October 09, 2009
The version of the SQL Driver 1.1 that was released in August was a preview release version.  Microsoft officially released the final version of SQL Server Driver 1.1 on October 6th.

Update: This article is considered outdated. I’ve started an IIS Tutorial Series on Talking to SQL Server with PHP on IIS.

Last time I posted about PHP deciding to remove the MS SQL Server Connection driver and library from the PHP 5.3 package, and mentioned that Microsoft now has its own version of the MS SQL Server driver for PHP.  I’ve decided to start playing around with it and after a few hours of no luck getting it to work with PHP 5.3 (it doesn’t show up in phpinfo), I’ve decided to do a search on it.  What I’ve found on the MSDN message boards was that the MS SQL  Server driver PHP, version 1.0 (the current and version), does not have support for PHP 5.3. (reference)  Not until version 1.1 comes out, at least. This is rather stupid considering now there is no direct MS SQL Server driver for PHP 5.3.  The only way I know of is to use an ODBC connection.

Update: This article is considered outdated. I’ve started an IIS Tutorial Series on how to install PHP and FastCGI on IIS 6.0.

With the release of PHP 5.3.0 introducing a lot of new features and bug fixes, it also comes in with a lot of changes for Microsoft IIS users.  The biggest one of them is the way that PHP is now installed on IIS.  The PHP 5.3 package now no longer provides an ISAPI DLL file (which I’ve been using).  The only way to do it is through CGI, in which you should (have to?) use the FastCGI module.  Depending on which version of IIS you have, the setup will be different.  (I have IIS 6.0 on a Windows 2003 server).  Microsoft seems to have gotten more close with Zend recently and provided better support on IIS that they even have a dedicated website for installing PHP on IIS and providing community support.  Everything you need to know for installing PHP on IIS is on that website.  PHP also now have a website dedicated to supporting PHP on Windows, regardless of whether you’re using IIS or Apache on Windows.

One of the big drawbacks I’ve found was that PHP decided to remove the MS SQL Server connection driver in the PHP 5.3 package.  Just adding back in the DLLs from the old PHP packages back in the PHP directory did not work for me.  Not only did they make it harder for IIS users to install PHP, they had to make it harder for those to connect to MS SQL Server.  Upon doing some online searches, the driver used in PHP was very old (which explains my post on trying to get it to work properly on previous versions of PHP).  Microsoft now has it’s own version of MS SQL Server driver (2005 and above) for PHP.  I have yet to install it, but it would have to be done on a development environment to redo any code using PHP’s old connection library.  I’ve also yet to find any documentation on it so I’m not sure of the details of the driver.

Update: September 24, 2009
Maybeme compiled a php_mssql.dll that works in the VC9 version of PHP 5.3. Note that the ntwdblib.dll files is still necessary. I haven’t gotten it to work personally, but it seems others have, so I’m sharing it for others who wants to try.

Download here: php_mssql.dll (right-click > Save Link As…)

Ever since I’ve began creating web applications that include more and more Javascript, some of my own, and some such as Javascript libraries and plug-ins, the need for me to optimize the amount of data to transfer to the client becomes more imporatant.  I’ve found that compressing your Javascript is one of the simpliest things you could do and save a few kilobytes on initial page load.

So far, the best compressor I’ve used is the YUI Compressor. YUI Compressor compresses Javascript files by stripping out unnecessary whitespaces, semi-colons, and replace local variable names with shorter names, decreasing the size of the file by about 30% in my experience.

The only few ways to run your code through YUI Compressor is through an online service, or by downloading the YUI Compressor to your computer and running it via command line.  I use the command line, but I’ve made using it a habit and without even having open up command line by just saving the command into my favorite code editors and just assigning a hot key to it. For example, Notepad++ has a ‘Run…’ option that lets you run external executables and saving that command line to some set of hotkeys (e.g. Ctrl+1).  In the command line arguments, you can set editor-specific variables for the filename, etc. such that executing the command can automatically take your script.js that you’re working on, compress it, and output a script.min.js file for you in the same directory.  It’s simple and you don’t even think about it once you have it all set up.  I’ve even made it a habit to compress all 3rd party scripts when possible to squeeze a few more kilobytes out of the overall transfer.

Of course there are other ways to save on transfer such as by making sure your server has GZIP compression turned out, and a few other methods, but making a habit of compressing your Javascript is one of the simplist thing you can do and can go a long way in saving a lot of bandwidth and improve user experience with less loading time.