1)  I don’t have any experience of this, I do know that DotNetNuke can be run in a web farm if that helps?

2)  If each portal is going to have different modules and a different configuration I would go for separate DotNetNuke installations.  If they are all going to be based on the same modules then you could keep them within one installation - this will make upgrading faster. – personally I tend to opt for separate DotNetNuke installations, if one site goes down the rest will continue running.

3)  If you wish to do content distribution then I would implement RSS feeds.

Does anyone else have any experiences they can share?

Thanks,

My one experience with this is that it's a pain. If you want to have one database, updated by two dnn installations--good luck with that! Do you want all the logins, customer data, etc available from both servers--so if someone logs in on one server, does some stuff, then logs out, then logs into the 2nd server--that they would be able to successfully login and see the 'stuff' that customer did be visible? If so, you might want to create a customer Membership Provider, that would check the login on each server, to see which server their login resides and transfer the user to the appropriate server.

I don't know of another way to do it. We will be having a similar issue, but because one of the sites will be a parent portal (using SQL Membership) and one will be a school portal (which will use AD Membership), so we will have to create some type of solution for this...sort of similar to your issue...

I'd be interested to know what solution you folks come up with...

Regards,
Andy H.