Solved

Architecture question relating to collaboration, projects, security

Posted on 2011-09-21
38
419 Views
Last Modified: 2012-05-12
Im setting up a 2010 sharepoint collaboration site.  Im having difficulty understanding how to setup the different teamsites so that users across departments can collaborate on projects.

For example.  I have people in Finance that need to work with people in Administration on a contract type document.

The site will have departmental teamsites.  HR, IT, FInance, Admin etc.  And in each of those departments will have its own set of rules regarding internal projects.

But when it comes to cross departmental projects im not sure if I should create a teamsite dedicated to projects across all departments or somehow have a more sophisticated governance that allows people in HR to be able to view teamsites in Admin if they are so invited to.  Hope that made sense.  

Thanks in advance.
0
Comment
Question by:rochestermn
  • 20
  • 18
38 Comments
 

Author Comment

by:rochestermn
Comment Utility
See attached.
Capture.JPG
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
For cross departmental projects like contract management I would recommend separate sites and grant access to the teams that need it.
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
For cross departmental projects like contract management I would recommend separate sites and grant access to the teams that need it.
0
 

Author Comment

by:rochestermn
Comment Utility
When you say seperate sites do you mean within the main site (ie subsite) or seperate
web application for cross dept projects?
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
I would probably create a separate site collection, as that isolates the security permissions. It might be confusing to have Contracts live under one department's site, but have completely different permissions and have co-ownership with other departments.
0
 

Author Comment

by:rochestermn
Comment Utility
So im just wondering how to set that up.

So if I hear you right I have a main site that has departmental team sites.

But then another sharepoint site for cross dept projects.  Is that what your saying?

for example:

site1:  sharepoint.departments

site 2 sharepoint.projects
    sharepoint.projects/projectA\
    sharepoint.projects/projectB\

These projects sites are global too anyone I choose to make part of the project team.

0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
I'm thinking more that you create wildcard managed paths like the following

- /departments/
- /projects/

And then create new site collections on those paths. So:

- /departments/HR
- /projects/A

These would be for secured sites. Departments would be for internal operations, and only accessible to that department (as a general rule). Projects would be for focused purposes, and probably have separate permissions as well.

However, if you have a requirement to roll-up content across sites using something like the Content Query Web Part, that only works within a site collection. So for example, for the corporate Intranet (which is corporate wide content, not department internal operations - ie, team sites), you might do:

/ (Intranet root site collection)
/sites/HR (sub-site)
/sites/IT (sub-site)

Does that make sense? Here are a couple images on creating managed paths for new site collections. I mocked them up in a test VM.


2011-10-05-1745.png
2011-10-05-1748.png
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
Sorry, I think I confused the Intranet example. I meant to convery:

/ (Intranet root site collection)
/HR (sub-site)
/IT (sub-site)

Again, this would be for "published" information available to the rest of the company. Not collaborative, secured team sites. Having each department as sub-sites would allow you to easily roll-up and aggregate information on the home page or across departments using functionality like the Content Query Web Part.
0
 

Author Comment

by:rochestermn
Comment Utility
Ok.  I think I understand but what about a top level site that points to both?

If I want a single page that has links to both a publishing site and a collaboration site and is at / the root what type of site should that be?  Im assuming blank but not sure what template to use for a single page that is just serving as a starting point.  Or should it be a publising portal with just a default page?
0
 

Author Comment

by:rochestermn
Comment Utility
See screen shot to see what central admin page im on.  It comes up when launching the farm wizard.
Capture.JPG
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
What else is going to be on that page? The other content should dictate the template, unless it is meant to be just a links page.
0
 

Author Comment

by:rochestermn
Comment Utility
Thats a good question.  Maybe I should just split them up and not have a front door.

I think I know where your going with this.  Aggregation?  Because you cant roll up anthing to a blank site.

I guess the collaboration start page should just be a teamsite then.

sites/departments/home would be the start path.

The publishing site would be on a different collection?  Or managed path?

sites/intranet/home

The publishing portal will have links to useful info for company employees.

I really appreciate your help.  I havent had training yet and your being a huge help.
0
 

Author Comment

by:rochestermn
Comment Utility
If I have the sites managed path already cant I just use that.

For example:  sites/projects or sites/departments

vs /projects or /departments?

I would create a new collection at sites/departments/ and sites/projects

The intranet publishing one will be sites/intranet

Let me know what you think.

0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
Well, my recommendation was to have each department's site as its own site collection. This would isolate security and content as needed, and reduce complexity of administration moving forward. The model you are now thinking about assumes all the sites will be in a single site collection (departments).

If you wanted to have a directory of team sites and project sites, you could create a page on the Intranet and have the listing be created as part of the site creation process, or by querying and populating the list based on the URL (/departments or /projects).
0
 

Author Comment

by:rochestermn
Comment Utility
My boss wants an intranet publishing site that comes up when an employee first opens the browser.  
This would contain links to published documents for all employees to see for example HR policies or Finance reports.

He also wants a site for collaboration.  Teamsites where each department can upload documents to department librarys and submit expense reports for approval.  

Also included in this would be the ability for employees to collaborate on projects across departments.  This may be another site collection in of itself.

So the trick is setting up this architecture.  I do not know if I can or should have one site collection for intranet one for teamsites/depts and one for projects.  Also I am not fully understanding what managed paths accomplishes.  Im pretty sure the document libraries from the teamsites need to be shown on the intranet site.  For example if somone in HR changes a policy document then it should be linkabe from the intranet HR page for viewing by all employees.

I really appreciate all your help I may have only one shot at setting this up correctly.
0
 
LVL 16

Accepted Solution

by:
jessc7 earned 500 total points
Comment Utility
Obviously you need to architect it for your organization's needs, but based on what you are telling me, I still receommend using the following strategy:

Intranet
One site collection, multiple sub-sites for departments, initiatives, etc. Published information and items like Announcements can live at the each of the sub-sites, and then can be rolled-up to the Intranet home page via Content Query Web Parts, etc. The Intranet is where all published, organization-wide information should live in its "finalized" form.

Team Sites / Collaboration
A site collection per department. This would be a site collection to let them work on A) draft information that will eventually be publised on the Intranet and B) internal operations information and data for their teams. The latter is either information that is confidential, or the rest of the organization just doesn't really need access to, or to be able to search on.

Projects
Depending on the nature of the projects, these should probably be their own site collections. This is a little more grey, as you may have highly-related projects that should be in the same site collection. For example, if you have a site collection for "Recruiting / Onboarding", you may have multiple projects that have highly related data with shared permissions that should all be contained in the same site collection. You will have to give a little more assessment to the projects to determine if the data needs to be readily shared with other business processes, and if the security permissions are very similar to related projects. Mapping out the security and related business process should help you determine how to set each of these up - as their own site colelctions or shared with other projects.

Considerations
- Having Intranet broken out from Team Sites allows you to make a better search experience. If Team Sites are locked down to only the respective teams, the rest of the organization won't have to wade through the Team Site content to find the "finalized", published data within the Intranet in the search results. You can also configure anything that lives at the Intranet URL as Autoritative Pages within the Search configuration in Central Administration, increasing their rank in the search results. You can also create a search scope that searches only content on the Intranet, and excludes everything else. You can also set tagging policies (Enterprise Keywords and Managed Metadata) for content that lives on the Intranet to help with search queries and adding refinements to the to search results pages. Basically there are a lot of benefits for treating content that lives within the Intranet different than content that lives in the Team Sites.
- I recommend you not allow departments to link to content from the Intranet to the Team Sites, for some of the reason listed above and others. This dillutes the purposes, and you will eventually run into security permissions issues, and people potentially being able to search and pull up more content than they should. This potentially means having to give a little more thought to the publishing processes (getting content from Team Sites to Intranet), but it will save you confusion in the future.
- People will eventually ask for a way to have managed links or a directory to the sites within the Team Sites and Project Sites. If you enable User Profiles, some of this can be automatically managed with the Memberships functionality. You may also consider having a master directory of sites for users to look through. You might also consider creating standards sets of links that each job role needs, and put them out via Audiences to the Intranet Home page, their Profiles, etc.
- Managed Paths don't necessarily enable any of the above functionality, but they do give you a way to designate what the site collection's purpose is. Is it a Project site? Is it a Department site? etc. This can serve as reminder for you and members of the site, and may also give you a way to separate out sites if you are running queries or ways to automate listings. Not needed, but you may find it a nice-to-have-done in the future.

Hopefully this is all helpful. Somewhat of a minor brain-dump. :)
0
 

Author Comment

by:rochestermn
Comment Utility
I really really like this advice.  This is for a city government so its pretty segregated across teams.

I like the idea of having the intranet on one site collection so search is occuring only on the intranet and not being wasted on collaboration sites.

Im a little suprised by the one collection per dept on the collaboration site but there more i think about it the more it makes sense because this is dept only access.

The projects site is the big mystery here.  I have to be able to allow multiple people participate in workspaces etc.  I think this being on its own collection is a must.  Im going to mull this over and let you know what I think.  I just wanted you to know ive read this and appreciate it a ton.

0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
Sounds good - I'm glad I was able to help your thought process!
0
 

Author Comment

by:rochestermn
Comment Utility
So in the case of departments.

If I have my department paths in seperate site collections as below.

/teams/IT
/teams/HR

And lets say there is a document library in IT that has a content type/document that needs to be routed to someone in HR for approval am I going to be able to accomplish that with the workflow in that scenario?

Or in those cases would I need to have one site collection with subsites.
/teams/IT is a teamsite
/teams/HR is a teamsite
vs being on seperate collections.

I currently have a site collections for intranet home, a site collection one for each team/dept, and one for projects that would be for cross dept projects.  /projects/roadconstruction/hwy95.

Im not sure if I need to go with one site collections for teams and just get more granular with groups and permissions or seperate them via site collection.  I like them segregated but...if workflow needs to have an approver from HR and the document is from a Library in IT im not sure if I can do that if there in seperate collections.

I really appreciate your help.

0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 16

Expert Comment

by:jessc7
Comment Utility
Do you think that might be more project-like or specific business process related?
0
 

Author Comment

by:rochestermn
Comment Utility
Im a little worried about content rollup also.  What if I need aggregate information from the depts on a dept home page?  IN that case Im afraid all the teams would have to be in the same site collection.

For sure I know that the publishing intranet site will need to have links to documents that are published by each dept.  These documents would be published from the document libraries or pointed to somehow im not sure how that works between intranet site and collaboration sites.

I know this question is a grind but were getting there. :)
0
 

Author Comment

by:rochestermn
Comment Utility
In the case of document routing it would be inter-office day to day type routines that require a person in Finance to participate in a approval of a workflow.  Say expense reports or employee change requests.
0
 

Author Comment

by:rochestermn
Comment Utility
But the library where the content type exists would be in say /teams/IT and originate from a library in /teams/IT but it would involve being approved by someone on another team who in this case in on another site collection currently.
0
 

Author Comment

by:rochestermn
Comment Utility
By the way your response here:  10/23/11 04:30 PM, ID: 37015105 was the best  most concise advice ive ever gotten from any person or any book or any internet page.  

It may have answered some of my latest questions and perhaps Im still asking the same questions I and I apologize if that is the case.  I appreciate your patience.
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
- What content would you see needing to be rolled-up from the department level sites?
- I would create separate sites for cross-departmental business processes like Expense Reports and Employee Changes. Your situation may be different, but in that past I have treated those workflows as their own project level sites, specifically because they are cross-departmental in nature. I wouldn't argue strongly against a different solution, but I would caution you on given other departments access to a certain department's team site. It could confuse roles/purposes in the future.

Thank you for the feedback on the comment #37015105! I really appreciate that type of feedback. I have been trying to work out a good message for basic architecture for awhile, so its good to hear it is useful!
0
 

Author Comment

by:rochestermn
Comment Utility
But see that is where maybe im over thinking things.  For some reason I have it in my head that if you have departments on seperate site collections then collaboration dies.

So maybe not.  Maybe if I have an employee change form for when someone leaves the company
I have a document type that IT can use that originates from a manager clicking new on a document library and then saving it to the doc library which fires a workflow that goes to an approvers group.

Well if Sally in HR needs to be in that approvers group is there any problem just adding her to the approvers group that is bound to the IT teamsite?  God I hope that made sense!  

Meanwhile Sally is a contributor in the HR teamsite.  Forget what I said about content roll up for now.  Again I might be overthinking that too.  I just need to make sure that if I go seperate team site collections that I can collaborate across depts.  For example what if ALL dept teamsites need access to the same content type?  Each dept team site in this scenario is a top level site.  So therein lies my confusion.  Thanks again.
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
I understand your example, and you're definitely thinking through good things. :) I'm not saying this is the *only* way to go about it, but in the past for cross-departmental business processes (i.e., not just sole department internal operations), I have created site collections by topic. So for instance, maybe a site collection for Employee Onboarding and Changes. That could contain the forms and the workflows for cross-departmental processes for things like onboarding, name change, terminations, etc. This would let you give cross-department access, which still retaining the security and isolation for separate department team sites. Again, not the only way, but has worked well for me in the past.

As for content types across site collections, that is one of the things SharePoint 2010 addressed with Content Type Hubs - see here:

SharePoint 2010 – Share Content Types Across Site Collections
http://www.endusersharepoint.com/EUSP2010/2010/05/31/sharepoint-2010-share-content-types-across-site-collections/

Content Type Hub FAQ and Limitations
http://blogs.msdn.com/b/chaks/archive/2011/02/09/content-type-hub-limitations.aspx
0
 

Author Comment

by:rochestermn
Comment Utility
I think the light bulb just went off.  Let me think about his for a bit.

So that is where content type hubs comes in to play.  hmmm.   Ok let me think this over because I do really want to keep things isolated dept teamsite wise.  One thing I want to make clear to is that right now we have only standard version not enterprise.

I want to make sure I dont want to have too many site collections either though.  I do have one called projects that could be used for anything I want regarding collaboration. Another thing to think about is backup and restore.  What if HR blows away a library and I have to do a restore.  Then potentially it affects every teamsite in the collection during the restore.  
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
That is another reason to have separate site collections, so you can isolate them in multiple content databases for recovery SLAs, etc.

Logical architecture components (SharePoint Server 2010): Content databases
http://technet.microsoft.com/en-us/library/cc263121.aspx#section7
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
You can also use Granular Backup in SharePoint 2010 for higher priority sites or lists/libraries within a collection:

SharePoint 2010 Granular Backup-Restore Part 1
http://blogs.msdn.com/b/russmax/archive/2009/10/21/sharepoint-2010-granular-backup-restore-part-1.aspx

SharePoint 2010 Granular Backup-Restore Part 2
http://blogs.msdn.com/b/spses/archive/2009/12/18/sharepoint-2010-granular-backup-restore-part-2.aspx
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
Hopefully this won't confuse things, and maybe you've already seen this, but here is some sample site collection breakouts in a TechNet article:

Design sample: Corporate deployment (SharePoint Server 2010) - Site Collections
http://technet.microsoft.com/en-us/library/cc261995.aspx#section9

It may not match exactly what I've been saying, but maybe it will give you more considerations for your environment.
0
 

Author Comment

by:rochestermn
Comment Utility
Well here is what I have now.  See the attachment.  The root is going to be the intranet.

Kind of scary but every site collection is in the same db wss_content.

Another issue is we have a dns record of citynet and im trying to get the alias to work.

For example:  citynet brings up the root in the browser - this works.  I edited the host record of the default in iis to have an alias of citynet and hard wired the machine ip.

BUT I cant get this to work with the other sites.  For example:  citynet/teams/IT doesnt work but rochsvr78/teams/IT does.

I know off topic but...if you have any advice it would be great.  Thanks for all the links. I will take a look.  I feel very dangerous with this.
0
 

Author Comment

by:rochestermn
Comment Utility
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
In addition to the host headers in IIS, did you extend the web application inside SharePoint and have it reference citynet?

http://technet.microsoft.com/en-us/library/cc261698.aspx
0
 

Author Comment

by:rochestermn
Comment Utility
No I did not.  Here is what IIS looks like.  My background is more development engineer so alot of these admin tasks are new to me.  I wasnt sure if I should put the alias on the default website or the sharepoint website.

See attach.
Capture.JPG
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
I'm not positive if that is the right site in IIS or not. It depends on how the web appication in SharePoint was created. Typically the default name is "SharePoint - 80", the site below it in IIS.

Putting the name in the host header is only part of the process. The problem with stopping their is that SharePoint doesn't know it should be answering and resolving links for "citynet".

My advice is either re-create the web application or extend the existing web application through Central Admin. When you extend/create the Web Application, tell it to resolve with the host header "citynet".
0
 

Author Closing Comment

by:rochestermn
Comment Utility
This was the best help Ive ever gotten on EE.  Absolutely phenomenal!
0
 
LVL 16

Expert Comment

by:jessc7
Comment Utility
Thank you! It was fun dialog!
0

Featured Post

What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

A question that is asked often, is how to generate sequential numbers in InfoPath Forms. The best way to achieve this is to use a SQL database, along with a stored procedure and a web service to connect Forms Services to the DB. The first thing t…
For SharePoint sites, particularly public-facing ones, there are times when adding JavaScript, Meta Tags, CSS Styles or other content to the page <head> section is more practical than modifying master pages.  For instance, you could add the jQuery l…
Internet Business Fax to Email Made Easy - With eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, fr…
Illustrator's Shape Builder tool will let you combine shapes visually and interactively. This video shows the Mac version, but the tool works the same way in Windows. To follow along with this video, you can draw your own shapes or download the file…

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now