We have several ASP.NET systems that are being considered for DNN conversion. Currently each of the systems uses its own SQL database and a common User/Member details database for authentication. We are not sure (1) if each system will run within its own DNN intance or it is better to have seperate intances. (2) If the system specific (Sensitive/protected)SQL tables, SP's etc should be stored within the DNN database or if it is a good practice to seperate system data from DNN specific details. (3) If there will be performance issues when multiple DNN systems all run under a single DNN instance sharing a single DNN database that contains system tables and DNN specifics for all. (4) What is the DNN guidelines for easy maintenance in such instances. Would appreciate any and all help. Kindest regards!!

Each installation of DotNetNuke requires an instance of IIS and a MS SQL Server database. Each installation can host one or more sites or portals. All of these will be in the same database.

It is also possible to maintain one portal per installation, in which case each install will have its own database.

Often, the web servers (IIS) and the database are hosted on different computers.

How you do this will depend on performance, size of the site, number of users, number of simultaneous users, etc.

I prefer to keep unrelated sites/portals in separate installations. But you can certainly host multiple installations on a single IIS/MS SQL configuration.

We have multiple sites hosted on a system that features separate web server and MS SQL servers, but with multiple installations. We also have several sites hosted in a single installation. For low traffic sites that doesn't present a problem.

The real answers depend on the nature of the sites and the traffic that they must serve. I hope that is not too fuzzy of an answer to your question.

Thanks a lot Joe, As you say we should first get a handle on the performance requirement, size of the site, number of users, number of simultaneous users etc before proceeding. Having heavily accessed system data mixed up in DNN database seems a bit scary though. Will the page load / subsequent processing time etc be attrocious when the DB is being hammered by other apps including non-web applications that runs queries/reports etc.

Single VS Multiple DNN Instances

what if we have geographically seperated teams developing / supporting the individual (sub)systems/child portals that are to be implemented within a single DNN instance. Assuming each team has its own local test and UAT environments (having copies of productionLike DNN database for development and testing). How will the individual teams deploy their own modifications without affecting the others/systems? I see from posts on module development that Modules and Skins can be packaged. How about new pages or page changes? How about DB changes that arise outside of module, Skin package installations. Can page related changes be packaged from the individual development environments and installed on the production server? Won't there be conflicts even on database objects like TabID, Module ID..etc? We are hoping to build an SVN repository for tracking versions of existing source files. However I am not sure how would one keep track of the Page/Tab, DB changes when multiple teams contribute on top of the changes typically applied on bhalf of non-web apps.
Would appreciate any and all comments...

Yes, you have identified the issues. Those all "might" be good reasons for having separate installations.

With Content Management Systems, and with the website being defined partly in the web directory and partly in the database, the software development model -- SVN, etc. -- doesn't work very well.

You can severely limit the number of people who can change the live site(s).

Can you can package up pages and sites. There's not an easy way to update a page from a dev site to a live site, except for the Enterprise version of DotNetNuke. As I understand it, though, the update/publish works only for HTML modules.

Joe,
Thanks a lot. We appreciate your comments very much. I guess we have a bit more learning and planning to do before pushing ahead full steam.

I'll be happy to help ... just ask questions.

If we go with multiple instances of DNN running in production how will we handle the need to centrally maintain Users, UserRoles and UserProfiles? We have to avoid duplicating user profiles as a given user may have to access multiple apps with different/same roles. Can DNN be made to look at an external (common) "Authentication" DB for this purpose? Currently we have a common DB shared by all apps for user authentication/authorization.

You can handle authentication with a custom authentication provider. Keeping a common set of users, roles and profiles is more difficult and requires other custom providers.

If all of your portals are within a single installation, you can use a module like Multi Portal User Sharing from Avatar Software. I am using it on one installation and, for the most part, it works well. There are a few minor issues, but not significant.