Windows

I accidentally deleted my "Show Desktop" shortcut icon today. I guess it's one of those features I took for granted, because I sure missed it once it was gone. After a little digging on another computer, I've figured out how to restore it.

Step One:

Create a text file with the following contents:

[Shell]
Command=2
IconFile=explorer.exe,3
[Taskbar]
Command=ToggleDesktop


Step Two:

Save that file as "Show Desktop.scf" and place it in your Quick Launch folder (%USERPROFILE%\Application Data\Microsoft\Internet Explorer\Quick Launch). %USERPROFILE%,

The best source to identify the application that created a file of unknown origin: FileXT.com. Assuming you have a file extension, this web site maintains a database of information about programs' file extensions.

The Apache Software Foundation's Tomcat servlet container was developed with an external module to connect it to other web servers using a protocol called AJP. The code is implemented in a project called JK. It is often referred to as mod_jk, because that's the name of the Apache HTTPD module. For some reason, the implementation for IIS is called ISAPI_Redirect.

The connection between IIS and Tomcat (or any of the numerous other servlet containers that have implemented AJP receivers to work with JK) is relatively simple. The JK DLL is installed into IIS as a filter + extension. It is configured to activate itself on certain URL patterns. For those patterns that match, the DLL sends an AJP packet to the servlet containers (called "workers") that have been configured. Assuming the servlet container has an AJP listener turned on, it then responds with the content of the response.

Note: Communication via AJP can be configured to happen on any port. By default, the port is 8009. AJP is not a secure protocol, so this port should be limited to communication between internal servers. Port 8009 should not be open on the external firewall.

Installation

First, download the JK 1.X Win32 binary from the an Apache mirror:
http://jakarta.apache.org/site/downloads/downloads_tomcat-connectors.cgi

If using IIS 5 or newer, download the isapi_redirect-1.x.exe. The EXE installer is the most convenient installation method.

The installer places all its files in C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\. Example (usable) configuration files are placed in the conf subdirectory.

Registry configuration is also set up at HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0. The registry keys point the ISAPI dll to the configuration files in C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf.

You'll also find a new Virtual Directory, called jakarta in the IIS Web Site configuration window. This directory is needed to forward the requests on to the application server, although it will not be present in your site's URLs.

Setting up a Context

To set up a context (an application hosted in a subdirectory of the site), you need to edit the
uriworkermap.properties file in the installation folder. This file maps URLs to workers. A "worker" is an instance of Tomcat, Jetty or another application server that supports the AJP protocol. The term more accurately applies when mod_jk is used in a load balancing environment.

The uriworkermap.properties simply identifies URL patterns that should be forwarded to an application server. The URL will not be changed in the process, so IIS mapped URLs must be identical to the context/URL configuration of the application server.

For example, assume we have applications (contexts) called accounting, intranet, and development set up in Tomcat. When using Tomcat's own HTTP, the URL for the accounting application woudl be http://localhost:8080/accounting. To set up this application to be accessed through IIS, we'd modify uriworkermap.properties like so:


/accounting/*=ajp13w


In this case, ajp13w identifies the name of the Tomcat worker. The name ajp13w is the name of the default installation worker (which will likely be configured correctly if IIS and Tomcat and IIS are on the same server). The mapping indicates that all requests to the accounting subdirectory be sent to Tomcat.

Note: You'll need to restart IIS to get the new URL mappings to activate.

Division of Labor

You may want to divide responsibilities so that IIS handles static files, and only dynamic content is served by the underlying application server. This is typically done by unmapping certain file extensions in the uriworkermap.properties file. Unmap directives are identical to mapping ones, with an added ! as the first character.


!/accounting/*.jpg=ajp13w
!/accounting/*.gif=ajp13w
!/accounting/*.png=ajp13w
!/accounting/static/*=ajp13w


The above directives would cause mod_jk to not forward JPG, GIF and PNG requests for the accounting context. It also causes the entire static subdirectory to be ignored by mod_jk as well.

Now to make sure IIS knows where to find these files, we'll need to set up a Virtual Directory where these files can be found. In this case, we'll set up an IIS Virtual Directory called accounting (it must be the same as the context). We'll point that virtual directory to the same one that hosts the application server files.

HTTP Authentication

In many cases, you'll want the application server to continue to manage authentication. This setup is more portable (the same username database will be used on any web server), and it saves the effort of configuring usernames and passwords through Windows or IIS.

If your application uses HTTP Digest or Basic authentication, you'll need some special configuration, as IIS will normally try to hijack the application servers authentication attempts.

By default, the jakarta Virtual Directory has its own Directory Security settings turned on (Integrated Windows authentication is enabled, I believe). If you want authentication to be handled by the application server, you'll need to turn off all but Anonymous access in the Directory Security tab for the jakarta Virtual Directory. The same applies to context Virtual Directories if you're using them.

I recently found an article on ASPN that demonstrates using Python to modify Environment Variables, especially the PATH variable.

The key to the article is that it demonstrates a way to make Environment Variable changes persistent. It does this by modifying the registry directly. After editing the registry, it causes a broadcast to be sent indicating the change in system settings. Although the example is in Python, this process is possible with any language that can access the Win32 system API.

After all these years, Windows still provides a tiny little edit box for editing the PATH (and other) environment variables. It's especially annoying when setting up scripting languages like Python, Perl, Ruby and Groovy for PATH access.

To make this setup process easer, it helps to define HOME variables for each scripting language. To do this, we need to use the Registry Editor to add new environment variables.

1. Open the Windows Registry Editor: Start->Run->regedit.
2. Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.