While there are disadvantages of that configuration, it can be done, and here's how to set it up. There's a variety of reasons why you might want to serve pages from a remote share, where the one I hear most often is so that ColdFusion can be run in distributed mode away from the webserver machine, where a firewall might exist between the two servers. In distributed mode rather than duplicating the application directory hierarchy on each machine so that IIS can serve static content from the "front end" and ColdFusion can serve dynamic content off the "back end", both from the same relative location under their local directory tree, you could instead use a UNC path so that ColdFusion reaches out to the webserver for the dynamic content. This allows all content to reside in one physical location while separating the application server from the webserver. I've also heard reports of wanting to use UNC paths for the document root so that a cluster of ColdFusion servers can read from a single source without worrying about synchronizing the content in multiple locations.

Translating Webserver Paths to ColdFusion Paths - The webserver will form the "real path" to the requested resource by concatenating the path to the document root with the path to the requested file. So assuming the document root is at C:wwwroot and the request is /foo/bar.cfm, when the request first passes over the JRun filter, the JRun connector will see C:wwwrootfooar.cfm and since the *.cfm is a pattern mapped to the ColdFusion servlet mapping, the connector will pass the request to ColdFusion and the webserver will forfeit handling of the request. The ColdFusion server will then attempt to resolve the path C:wwwrootfooar.cfm and read/compile/process the template. The webserver actually never even needs to have read access to the document root at all for dynamic/cfm content, and only ColdFusion will be responsible for resolving the path and reading the template source.

In order for ColdFusion to look in a UNC path for a template, it must have received a translated path that includes the UNC path, and that comes from the webserver. In order for the webserver to tell ColdFusion to look on a UNC path, the webserver Document Root must be configured as a UNC path. If you intend to have the content local to the webserver machine, then you can just set the Document Root as a UNC path having its own machine name. You could have all the content on a third machine, and then both IIS and ColdFusion will reach over the UNC path to the remote document root.

Access Control over UNC - In order for ColdFusion server to access dynamic content from a UNC path, it needs to run as an appropriate domain user account. From the Windows Services in the Control Panel, the ColdFusion server Service could be set to run as the domain user account instead of System, but notice in the Log On tab that only the System Account can interact with desktop. I found that when running ColdFusion as a domain account from a Windows Service that it could not access content over a UNC path (resulting in a ColdFusion 404 error), but when I ran ColdFusion from the commandline while logged on with the same user credentials that the templates could be resolved, read, and run. In my case, ColdFusion must not only run as a domain account but must also be able to interact with the desktop. For more information on this, see this article from Microsoft.

Since (in my experience) ColdFusion must be run from the command line rather than a Windows Service, the user that started ColdFusion must remain logged in, although the screen can be locked, but this means that ColdFusion won't automatically start when Windows is rebooted. There is a workaround for this by using the AutoAdminLogon feature of Windows while putting a shortcut to a batch file that starts ColdFusion in the Start > Programs > Startup menu; see this blog entry for more on that.

Separating IIS from ColdFusion and separating the content from IIS and ColdFusion will slow down performance since it just couldn't be as fast as when all components are on the same machine, but if you could run Gigabit Ethernet between the layers then you can certain gain some of that performance back.

I've tried using UNC paths as Virtual Directories in jrun-web.xml but was unsuccessful. Specifically I tried mapping / to a UNC path while escaping the path either as \\machinename\sharename or //machinename/sharename, but neither option worked, although a mapped drive to that UNC path worked when the drive letter was used for the system path in the virtual directory. This solution might work for you if you only have one webserver connected to ColdFusion since a / mapping will override what the path that webserver tells ColdFusion, but if you have multiple website instances connected to one ColdFusion instance then a / mapping will route all requests to the same location.

Here's a few screen shots to help make sense out of this:

  • Configure webserver Document Root as UNC path, configure "Connect As". No need to run IIS Service as domain user if using "Connect As"
    Configure IIS for UNC path
  • Stop ColdFusion Service; Set the Service to Manual; ColdFusion can only access remote UNC path when allowed to "Interact with Desktop", but cannot configure Windows Service to run as domain account and interact with desktop since only "Local System" account can interact with desktop as configured on the Logon tab of the Service
    Stop ColdFusion Service
  • Log on as domain account user, run ColdFusion from commandline; ColdFusion runs as that user account and can interact with desktop
    Run ColdFusion from Commandline
  • Dump CGI scope to view CF_TEMPLATE_PATH and PATH_TRANSLATED
    Run test page to view cgi scope info