What's so bad about running an IIS web application from an UNC share, as suggested in DotNetNuke docs?

I've been taught in the past that it is unwise to run a web application from an UNC share. Reasons I remember are security, rights and authorization trouble and performance. However, in the DotNetNuke documentation it says:

The web farm configuration that DotNetNuke initially supports involves two or more front end w开发者_运维百科eb servers ("web-heads") whose IIS website root directories are mapped to a common UNC share on a remote file server. The UNC share contains the application source code as well as any static content for the individual sites.

Somehow this sounds to me like a poor-mans configuration and I feel like opening a potential Pandora's box. Is it wise to follow DotNetNuke Corp's suggestion here?

There is nothing inherently wrong with using a UNC share. At a previous company we operated dozens of web servers and they all used UNC shares (not on DNN). There were over 80k paying subscribers of which 10's of thousands used the applications every day. It worked very well.

To address Mitchel's points:

1.) Single point of failure is only an issue if you make it an issue. There is plenty of redundancy available in the various SAN/NAS solutions.

2.) IO will not be an issue with any decent SAN or NAS. I have never had a problem with file system watchers. DNN doesn't directly use any, in the unlikely event that the built-in ASP.Net watchers created a problem I would probably disable them.

3.) I don't see security as any more of an issue than any other solution. You must be sure to control access to your files and setup permissions appropriately. With local disks you may choose to leave permissions more open than on a network, but you probably should secure both equally well. There is an extra configuration step related to using a UNC path. The extra effort around configuring security will be minuscule when compared to the weeks if not months of effort involved in creating a site that is worthy of a web farm.

I totally agree with Mitchel's opinions on why not to use file synchronization.

I know there are some people out there running DNN sites with file synchronization. I don't know of any who have not had to work around issues caused by the file synchronization. Personally I doubt that getting a site running well with file synchronization is cheaper than using a UNC on a SAN once you count the labor spent sorting out the quirks of file synchronization.

There are a few things that can become problematic when it comes to this type of configuration with DOtNetNuke.

1. This method although a "web-farm" scenario results in a single point of failure. The UNC share becomes your choke point and if it goes down all nodes go down.
2. Disk IO and configuration of network communication can be an issue. This is related to the number of "File System Watchers" that can be opened/maintained on remote content. THis issue isn't too big of a deal in MOST cases, but can be a royal PITA when it happens.
3. Security can be an issue, but is typically something that you just have issues with at the onset of the configuration. You need to be sure that you properly assign permissions to the user account so that it can have full access to the UNC share.

My guess as to why this is the "default" recommendation by DotNetNuke corporation would be due to the following. NOTE: these are ONLY my opinions.

1. This configuration provides the "least" complication when it comes to real-time content synching. WIth only one file system there is no need to talk about replication and things of that nature.
2. Default caching uses file based caching, with both going to the same system cache expiration is easy to manage. If replicated it wouldn't work.