Hello All,

At my day job, we're running in a similar situation as the individual who started this thread.  We have built our customer extranet around the Portal/Child mehtodology in DNN because:

1. I want to provide the ability for customers to customize their sites.
2. I want to automate as much as possible site creation.  This is extremely easy to do when using creating your own portal templates.
3. I want users at the root level to access other portals, but users at the child level to access only their site.

In my opinion, this is is a great way to use the Portal/Child implementation.

However, I am running a completely separate installation for our corporate web sites.  This allows me the ability to reduce the number of modules installed on either portal installation and keep better track of who's doing what on each portal.

At the end of the day, I make my choice on what the intent behind the site.  If it's function is pretty far from existing installs, then I would make a new instance.  If the portal is going to use shared functionality from installed modules, I would use Single Install/Multiple Portal approach.  If your portals are going to share functionality and use a "flavor" of single signon, then I would suggest Single Install, Single Parent, Multiple Children approach.  At least that's what I did.  Feel free to visit tricorbraun.com if you'd like to see our corporate web site in action.

 Amen Mitch!  Preach it!

What I've noticed is that in the community there is a faction of small-medium businesses who use portals and things work for them because they're small so they recommend that other people use portals.  What they don't realize is when you have 1600 portals, all of that money that you thought you were going to save on hosting comes back 10 fold in consulting, management, optimization, and nightmares

Portals are bearable when you're small, but if you have a serious project with a serious number of portals, it will eat you alive.

*** POP ***

HELP - I'm Still looking for an answer