So, it indeed is just what I had guessed: most people build their sites in parent portals.

agbl, your input makes me realize that the number of databases one is alloted plays a part in how many DNN installations one may have. In our case, we have our own hosting server for DNN.

Your questions are valid ones . . . I asked the same questions. I did some more digging and came upon these passages in the Professional DotNetNuke 4 book written by the core team:

"The only real distinction between a Parent portal and a Child portal is that a Parent portal alias has a simple URL attributed to it, whereas a Child portal consists of a URL and subdirectory name."

"To set up a parent portal, you must perform some additional steps. You first need to set up an additional web site in your IIS Manager with host headers for your domain name, and then create a DNS record to point to the IP address of your web server. Information on how to perform these tasks is outside the scope of this book, so please refer to your IIS and DNS help files for the steps."

So I guess that is what you guys have been doing. Since I've been building our sites (for our internal use) in child portals, I did not have to fiddle with IIS other than the initial DNN installation.

Agbl, the benefits of building child portals over the parent portals, besides the avoidance of additional IIS configurations, is that I can log in as host and can administer all of my web sites since they are all built under the same parent.

Nonetheless, the problems I have surfaced are that there are modules and skin objects that work in parent portals but NOT in child portals.

jc