What's wrong with running an IIS web application from a UNC share, as suggested in the DotNetNuke docs?

Question

In the past, I was taught that launching a web application from a UNC resource is not practical. The reasons I remember are security issues and rights and authorities. However, the DotNetNuke documentation says:

The web farm configuration that DotNetNuke initially supports includes two or more web servers with an interface ("web heads") whose IIS website directories are mapped to a UNC share on the remote file server. The UNC share contains the source code of the application, as well as any static content for individual sites.

Somehow it sounds to me like a configuration of the poor, and I feel like I'm opening a potential Pandora's box. Is it right to follow the DotNetNuke Corp offer here?

Answer 1

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

• This method, although the "web farms" scenario leads to a single point of failure. The UNC will become your decay point, and if it goes down, all nodes go down.
• A problem with IO and network communication configuration can be a problem. This is due to the number of “file system watchers” that can be opened / saved on remote content. This problem is not too great in MOST affairs, but there may be a royal PITA when this happens.
• Security can be a problem, but usually this is what you have problems with from the very beginning of the configuration. You must ensure that you assign permissions to the user account correctly so that you have full access to the UNC shared folder.

My guess about why this is the default recommendation from DotNetNuke is explained as follows. NOTE: these are ONLY my opinions.

• This configuration provides the “least” complication when it comes to real-time content synchronization. With one file system, there is no need to talk about replication and things of this kind.
• By default, caching uses file-based caching, and both outputs at the same time when the system cache expires are easy to manage. If replicated, this will not work.

Answer 2

There is nothing wrong with using a UNC share. In the previous company, we managed dozens of web servers, and they all used UNC shares (rather than DNNs). There were more than 80 thousand paid subscribers, of which 10 thousand used the application every day. He worked very well.

To refer to Mitchell's points:

1.) The only point of failure is only a problem if you make it a problem. There is a lot of redundancy in various SAN / NAS solutions.

2.) IO will not be a problem with any decent SAN or NAS. I have never had a problem with file system watchers. DNN does not directly use, in the unlikely event that ASP.Net embedded observers created a problem, I would probably disable them.

3.) I no longer see security than any other solution. You must definitely control access to your files and set permissions accordingly. With local drives, you can leave permissions more open than on the network, but you probably should both have the same good. There is an additional configuration step associated with using a UNC path. The extra security efforts will be negligible compared to weeks, if not months, of efforts to build a site worthy of a web farm.

I completely agree with Mitchell's opinions on why not use file synchronization.

I know that there are some people who run DNN sites with file synchronization. I do not know anyone who did not have to get around the problems caused by file synchronization. Personally, I doubt that getting a site that works well with file synchronization is cheaper than using UNC in a SAN as soon as you consider your work, sorting out the quirks of file synchronization.