Sitecore multiple sites implementation

Question

I have a client with 30+ organization units that operate independently. Currently all the OUs have websites managed by the client's IT department in seperate instances of a different CMS product. They decided to go with Sitecore because of its advertised multi-site features.

Unfortunately, the current (6.5/6.6) default implementation does not work for the following reasons:

1. Requires changes to web.config for every site change (add/delete).
2. All content items have to be under the "/sitecore/content" node. We would prefer to create multiple nodes under /sitecore e.g. /sitecore/OU1, /sitecore/OU2, etc...
3. All templates have to be under /sitecore/Templates. We would prefer to create "Templates" folders under each organization unit e.g. /sitecore/OU1/Templates, /sitecore/OU2/Templates, etc...
4. All Layouts have to be under /sitecore/Layouts/ and also in the same file system directory. This definitely gets messy as the sites increase in number. /sitecore/OU1/Layouts/ and /sitecore/OU2/Layouts are definitely preferable
5. We need to isolate the sites for administration. Each site administrator needs to login and see only content/items relevant to their site. So if we lock down/hide the top-level OU nodes, it makes it easier to maintain.
6. We also need to isolate the file systems so that a developer does not bring all 30+ sites down if they make a mistake in web.config.

At the recent Sitecore Symposium, Tim Ward presented on the different ways to implement multiple sites in Sitecore. Unfortunately, there is no way of knowing which products he is referring to. I wasn't there, but my boss attended. I have tried to get in touch with Sitecore, but haven't received a response yet.

I also contacted Sitecore requesting information on whether Sitecore Foundry is meant to address this need, but no response.

Anyone know of a way to implement such multiple sites Sitecore?

Answer 1

Sounds like Tim's multi-site solution is indeed something for you. It's meant for large scale multi-site platforms that require isolation and need to be fit for independent vendors developing for it.

Sitecore Foundry is not for you, it's meant for much smaller type of websites and does not offer any kind of isolation.

Tim's solution can be found here at github (which you probably already got from the slides):

You can e-mail him at [email protected] and he's usually pretty quick to reply.

He's also active on the SDN forums, assuming your have access to that.

Answer 2

I agree with Ruud that Tim's multi-site solution would probably best meet your needs, this is something that I will be looking in to soon as well, I wasn't at Symposium but it looks really promising for good separation.

1. Yes, unfortunately you need to add in a entry for each one.
2. You can set them up so they are /sitecore/content/OU1, /sitecore/content/OU2 etc
3. Again you can set them up as /sitecore/templates/OUCommon, /sitecore/templates/OU1, /sitecore/templates/OU2
4. Again you can put them in Sub-folders, buts gets messy as you say.
5. You can actually already achieve this. Break the permission inheritance so your Roles (specifically sitecore/Everyone) does not have read access to the /sitecore/content node and then each of your groups would specifically have read/write/delete access with inheritance to each separate site/media library. Add your users in to the specific role and they will only see the parts of the tree they have access to. You can also extend this to Workflow so only those users with permission can approve the appropriate item. Publishing becomes a tricky one though, but you can set Publishing.CheckSecurity=true, you just need to have your permissions set correctly. The Security Access viewer is really good at seeing the permissions that have been set for the different roles. But compared to Tim's multi-site solution, becomes an admin headache with that many sites.
6. Yes, a restart will cause all of them to restart! I would also like to see separation of the log files to make debugging the different sites better.

Answer 3

Unfortunately, Tim's multi-site solution did not work for our situation. What we ended up doing was to:

1. create multiple multiple containers under /sitecore/content (like jammykam suggested)
2. Create multiple IIS sites and Application pools corresponding to each container in [1]
3. Modify the rootPath attribute of the website site in web.config (for each site).
4. Modify the permissions so that users have access to their corresponding containers.

We still had to create templates under /sitecore/Templates and layouts under sitecore/layouts according to the sitecore convention. Isolation was achieved by seperating the IIS sites and application pools as well as permissions.