Can ColdFusion serve pages over a UNC path on Windows?

Viewing By Entry

Can ColdFusion serve pages over a UNC path on Windows?

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:\wwwroot\foo\bar.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:\wwwroot\foo\bar.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"
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
Log on as domain account user, run ColdFusion from commandline; ColdFusion runs as that user account and can interact with desktop
Dump CGI scope to view CF_TEMPLATE_PATH and PATH_TRANSLATED

posted on 27 July, 2005 at 2:39 PM.
ColdFusion | Comments (9)

Comments

my experience is a little different. I have 4 windows 2003 servers each all accessing a clustered file share over a UNC path - i have a domain service account which all the CFMX installs runs as (via Services and not the command line). IIS is connected to the fileshare using the UNC path and the 'Connect As' option. No 404 messages here despite not having 'allow to interact with desktop' checked on the service properties.

comment by johnb, posted at 7/27/05 1:12 PM

Thanks for the info. While I've heard that some people can connect without having Interact with Desktop checked, I've only been successful with running on the commandline. Obviously, if you can connect when running as a Service, that's the better choice.

comment by Steven Erat, posted at 7/27/05 1:15 PM

Steven,
Great post, as usual. We had this running for a few days, and we found that our increased network bandwidth was causing CF Server instability. That's probably because of the volume we operate at, but it would be nice if there were some way to decrease or eliminate bandwidth from the UNC host to the web server. We even had it running with trusted cache on. Is this normal? Now we're looking into automated content pushing solutions. thanks!

comment by Nathan Strutz, posted at 7/27/05 1:30 PM

Ya we do this quite commonly. Our Development machine loads code off a Net Apps Filer; due to firewalls this is the only way our machines and the dev web server can see the same directory. But other benefits are that the net apps filer is RAID 5, and has a snapshotting backup system. When it comes time to deploy, we use the Deploy feature in Visual Source Safe to copy the code to a staging directory with a sync tool detects it and pushes local copies onto the production web servers.

comment by Tariq Ahmed, posted at 7/27/05 1:43 PM

2 things -

First - why do you run CF from the command line instead of a service? I've not found a reason to do this. Even with multiple instance setups.

Secondly - SANs are fantastic for getting all of the servers to see the same content. But it's not cheap, and in addition to the SAN you're going to need a traffic cop (such as IBM's SANFS)if you're running Winodws. It works, and you get INSANE disk performance which in turn, results in very high web server performance.

Otherwise, good article. I've seen several MM forum posts askinga bout this kind of thing.

comment by Tom Forrest, posted at 8/3/05 7:19 AM

Tom, as noted in the blog entry, some Windows OSes or configurations require a process to interact with the desktop in order to gain access to remote resources over the network, and that Microsoft article was the closest explanation I could find.

The Log On setting for Windows Services has a check box for "allow service to interact with desktop", but the setting is restricted to the System Account. If running as another user, that check box is not available. Since the System account can't access the network resources, the Service must be run as a user account from the Service, but that disables the option to interact with desktop. In my experience, on Windows XP and Windows 2000, ColdFusion could not access the remote network when run as a proper user from a Service.

To permit ColdFusion to interact with Desktop, I ran it from the commandline instead of a Service, and doing so allows it to interact with the desktop by definition and lets the process run as a specific user account. This was successful for me, and for others that I worked with it was successful for them.

Some people have commented that for them ColdFusion can access remote network resources on other Windows machines when running the Service as a user account even though the option to interact with desktop is disabled.

If you can run it as a Service and access remote resources, then great... this is the easier option, but if not, then try the commandline.

comment by Steven Erat, posted at 8/3/05 8:32 AM

Hrm. That is really interesting. We've never had issues with CF accessing remote shares via UNC pathing (though I've never worked with CF on XP - just 2k and 2k3). However, we have CF configured to log in as a domain user - not a local user to the server. And we have the remote UNC share configured with the domain cf account permissions-wise.

The problem I see with your solution is in environments where multiple administrators need to access the server with their accounts. Or someone other than the primary administrator has to reboot the server for some reason. Running it on the command line means it won't come back until someone sits down and makes it happen. But, if it works, it works.

The only other thing I could think of is if maybe in a multi-instance environment you had issues calling different config scripts. But that's easy to deai with with the jrun service configurator.

comment by Tom Forrest, posted at 8/3/05 8:46 AM

Yep, that's right, I use my Macromedia domain account for testing, which is a local Administrator (its my primary workstation for several years now) and is in the remote Administrators group (on a lab machine I use all the time). I've reproduced the need for running from the commandline instead of a Service on other machines as well, and this has been the (Macromedia) solution for several customers attempting this.

Of course running as a service is better, and if anyone is really bumping into this it would be best for them to open a ticket with Microsoft for more about the limitations of Services or processes interacting with networked resources.

comment by Steven Erat, posted at 8/3/05 8:57 AM

If you serve content over a UNC path, you might sometimes get a 404 File Not Found when a 'hiccup' occurs on the network, and ColdFusion will cache the 404 error. Here's a solution to workaround that:

http://www.talkingtree.com/blog/index.cfm/2006/2/2...

comment by Steven Erat, posted at 3/8/06 8:27 AM

Calendar

Search This Site

This is an exact search only

About This Site

I live west of Boston and used to work at Adobe with ColdFusion and Flex, specializing in Unix & Linux. I recently graduated from CDIA in Pro Digital Photography. Curious about my banner image?