I am planning a new setup for a little more advanced site where the demands are a litte more complex.
The key setup is like this:
www.customer.com (the public site)www.customer.com/VisitorsLogedIn (a subsite to the public when a visistor is logged in)www.customer.com/b2b (a subsite for b2b)
This setup would be pretty simple in normal case, but I want to do these three to be able to live there own life, meaning they have their own database and codebase.
The reason I want that is that they have their own schedule for updates and their own developer teams and so on.
Anyone knowing if this is a possible senario?
No, I'm not multisites expert but my thought is you can set up three separated sites, each point to an url as you listed.
If an user logs in on public site, then redirect them to the second site.
The only issue I see is to sync users between databases, looks like a custom membership provider sharing a database is possible (if you use OpenId or AD account then it'll be much easier).
We've done similar setups in the past with virtual directories as apps in IIS. However, I do seem to remember it not being entirely supported by EPiServer at the time (this was EPiServer 5 and 6 websites).
Thanks for your feedback
I forgot to mention that all these sites are going to be Azure websites.
Quan, all authentications are done with federated security so that is no problem
As far as I know Azure Websites has to have 1 codebase. You could of course then setup 3 different Azure Websites with 3 different codebases - but I'm not sure you can do that on the same domain. Maybe some redirects are in order?
I would probably opt for 1 codebase - Updating Azure websites is pretty smooth - especially if you use multiple deployment slots.
I am right now trying out the virtual directory function in Azure, like they do in this article, will get back and report on the progress
It all looked good first, but then it complained over dublicated keys and so on in web.config.It was the same thing if I did it as a virtual directory on my IIS
Got it to work with the beautiful clear tag :)
The other approach you could take is Application Request Routing. This would mean you would have to drop another IaaS server in front of your Azure sites, which could all be set up entirely seperately. The ARR module, whigh is part of IIS allows you to act as a reverse proxy to route requests to particular servers / sites. This is obviously more expensive as you have another box (or more of you need some resilience), however you can scale out rather easily. It's a pretty common technique in the enterprise Apache world.
Disclaimer I've never tried it on Azure, but the above (which is a more complex scenario) seem to work well.
Thanks Mark, will check it out
I would also set the "dir"-sites up running sub domain names and put a reverse-proxy-something in front of them as Mark suggests. I recall a client of ours had that setup for an application we were integrating with. They were using Squid.
Have you considerd the licensing issues also?/K
Khan, yes that is a part of it, I am trying to figure out the license model for Azure now, but right now it looks like it will be three license instead of one, and that is a thing to consider in the choise for solution