MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Linking Collab & Publishing Sites

  Asked By: Madeline    Date: Dec 02    Category: MOSS    Views: 945

We're in the beginning stages of planning an enterprise MOSS07
deployment, and struggling a bit with organizing our site collections.
While we have well-established organizational structures (falling along
typical line-of-business boundaries) that will drive the top-level site
hierarchy, it's not clear how to address both internal organizational
collaboration and external information dissemination in a coherent site.
"Internal/external" here is relative to the particular organization, not
enterprise/public. Our desire is to provide an organization (at whatever
level of hierarchy) space/tools to create documents/information/content
that would be limited to the members of the organization. They would
also have a space for exposing certain pieces of that content (e.g.
finished workproducts) to a broader audience (the parent organization,
the entire company).

But while MOSS provides great tools for both these activities (Team
sites and Publishing sites, respectively), how do you align these with a
common organizational model? Do we end up creating two parallel site
trees, one for collab, the other for pub? If so, are there common ways
of linking across these trees (e.g. so that a member visiting an
internal collab site also has ready access to the public content):
links, aggregating web parts, common navigation? What are the
implications for navigation, management, etc.

Conversely, it seems possible in theory to create a "hybrid" portal
structure that combines both team sites and publishing sites, but I
expect that wouldn't work in practice due to the different needs for
security, content database management, etc.

Thoughts? How do other folks approach this seemingly common issue?



2 Answers Found

Answer #1    Answered By: Toby Singleton     Answered On: Dec 02

> We're in the beginning  stages of planning  an enterprise  MOSS07
> deployment, and struggling a bit  with organizing  our site  collections.

Aren't we all?

> Thoughts? How do other folks approach  this seemingly common  issue?

You raise a lot of good and common questions. I can't say any of this is
correct, but here's how we decided to do it:

We'll have two portals:

- intranet
- teamsites
- (and a 3rd 'mysite' portal, but that's a different topic...)

Intranet will be a publishing  portal. Read permissions will be turned on
for all employees.

Teamsites will be the collab  portal. Teams can decide who can/can't
collaborate on their sites.

If they want to work  on something collaboratively, they do it on their
teamsite within the team  site portal. If they want to share it with the
organization as a whole, they migrated it/copy it to their intranet

- it's much clearer to employees what each portal is for. 'public'
content goes on intranet, 'private' content  goes on teamsites. This way
there should be less support issues asking 'Bob can see this, why can't
- Most of the content will likely be stored in the team sites, on more
sites, and I don't want to deal with custom templates for these people.
This allows us to focus on custom templates for the intranet alone, and
also allows us to police that a bit better (without the overhead of all
that additional content/data)
- similar to the above, with less, but more general content being on
the intranet portal, it will be easier to police and maintain a
site-wide navigations sytem/IA that makes it easier to browse. Since the
intranet portal will be significantly smaller, I don't have to deal with
splitting it into multiple collections  and databases for backup and
restore purposes (which I will definitely be doing for the team site

- people have to maintain two sites
- content will likely be duplicated at times (though I'm not so sure
people won't be duplicating content even on their own team sites...seems
to be human nature)

The typical counter to the above seems to be to put ALL content into one
master portal and us security trimming to decide how broadly specific
content is shared. That sounds great  to me from a technical standpoint,
but sounds quite daunting from a support standpoint getting general
office workers to fully understand and comprehend how security works
within Sharepoint. It also seems that we'd end  up with a much more
varied set of templates as people begin to go off on their own choosing
whatever they feel like making it a lot harder to police.

In summary, we chose our method as:

Intranet portal = content and branding dictated and policed to ensure
ease of use, consistency of brand and IA and adherence so organizational

Team Site Portal = free for all. Do whatever you want. We trust that
your department knows what they want/need for their your own team sites.

Would love to hear other's opinions on this topic.

Answer #2    Answered By: Felipe Osborne     Answered On: Dec 02

I took a different approach  using WSS only. I created a top level
"mini-portal" page that points to a separate site  collection for each
organization that I support. The top page points to each office symbol in a
peer level arrangement rather than hierarchical. This makes managing the
sites easier, although I can make them appear hierarchical in a custom menu.
All of these are public  viewable (Intranet, not Internet) and this is where
information is published and service applications and forms are accessed.

Underneath each public page is a team  site for internal  collaboration. Only
team members  have access, and this is where workflow is used to control
production. Each team site has as many subsites as necessary.

Hope this helps.

Didn't find what you were looking for? Find more on Linking Collab & Publishing Sites Or get search suggestion and latest updates.