Return to

3.  Multiple IIS Sites
Prev Next

From time to time, users running a multisite solution are faced with the desire to have an IIS log file for each domain for statistics purposes. This article describes the challenges faced here.  

As a general rule, IIS sites must not share the same installation folder, or sql databases. This is especially true for sites with the client access and therefore allowing updates of the underlying databases. The reason for this is that what one site updates in the database is invisible to another site which will continue with its own inconsistent memory cache. Therefore this is not allowed for the Content Manager servers.  

It's another question with webfarm servers that usually only read data from web and extranet databases, but without updating the underlying database. Here it is okay for the webfarm to share web and extranet databases with other installations, as long as for example staging is used to clear the cache on all webfarm servers after a publish.

Obviously, in a traditional webfarm environment with multiple webfarm servers, an IIS log file will be created for each site. But what if you have a single webfarm server hosting multiple domains in a multisite solution and want a log file for each domain? Ingenious developers and administrators have tried to create an IIS site for each domain and have them all point to the same installation folder. This will indeed give you an IIS log file for each domain, but you may be facing other not so obvious challenges, which I will list here:  

  1. You are now actually having multiple sites for the same databases. Assuming that they - as webfarm servers - only have connections to the web and extranet databases, this is not a problem in itself, as they only read data but do not update.  
  2. You are now having a Sitecore installation with its own memory cache running for each IIS site you have set up. This means that you must ensure that each of these sites will have their cache reset after a publishing. As this can be done with webservices, this is definitely possible on each domain, but the issue must be addressed for the setup to work.  
  3. We assume that only one of the IIS sites will be able to update the Sitecore log file, and even if they are all able to do this, it will be impossible for support to see which entries come from which site. We may come forward with a solution to this in a future version as an added feature.  
  4. Unknown side effects. Be aware that this setup is not an official recommendation and has not been tested. We offer no guarantees that the setup will work for you, and any customer designs based on this must be tested thoroughly by the partner.  

The official recommendation:

We recommend that instead of having each IIS site point to the same installation folder, you duplicate the installation folder for each IIS site. You will still have to make sure the cache is cleared on each site after publishing, but you will be certain that Sitecore log files are updated correctly, and similar issues are avoided. This setup, however, requires that you have a runtime license for each site.

Prev Next