Information Architecture Scenario based example_AM102284811033 ...
Information Architecture for Fabrikam Industries Intranet
Fabrikam Industries is a fictional company name used for the purposes of demonstrating a typical approach to information
Scott Case, InterKnowlogy
This paper is intended to represent the process that a medium-to-large organization may undergo when deploying
Microsoft® Office SharePoint® Server 2007 in a practical scenario. Included are typical approach and implementation
techniques that may occur when planning, customizing, and deploying an Office SharePoint Server 2007 installation.
Rather than offer an overview of the features available to Office SharePoint Server 2007 and how to execute them, the
goal of this paper is to communicate the logical approach that may occur during development and deployment. Many
features in this paper are not applicable or available when using Microsoft® Windows® SharePoint® Services version 3.0.
This paper applies to both the business and technical stakeholders involved in Office SharePoint Server 2007
deployments. It is specifically targeted to the role of information architect, whose responsibility it is to determine how
an organization may best employ the features and functionality available within the Office SharePoint Server 2007
platform and the complementary desktop applications. This role is typically a hybrid, containing a subset of skills
traditionally associated with those of infrastructure manager, developer, business analyst, and information worker.
Information Architecture for Fabrikam Industries Intranet
Branding and User Interface................................................................................................................................................10
Metadata, Content Types, and Enterprise Search...............................................................................................................19
Roles and Training...............................................................................................................................................................36
Fabrikam Industries represents a well-established and globally recognized manufacturer. The products it engineers and
distributes are respected as much for their innovative design as for their reliability. To accomplish this level of quality,
Fabrikam Industries goes to great lengths to foster an integrated corporate culture where involvement in the success of
the organization occurs at every level. Building on ideas and efficiencies from across the organization has made it
Fabrikam Industries maintains offices in the continental United States and in key locations across the world. Because of
this, it faces challenges not only to its internal culture, but to overall business and communications in general. These
challenges begin with the most basic of physical locality challenges and include language, time zones, corporate data
centers, and international bandwidth limitations.
The investment in the Fabrikam Industries information architecture is significant. A company review shows the expected
signs of organic growth resulting from company acquisitions and historical transitions in IT leadership. Within its own
data center, it manages traditional service and line-of-business applications including e-mail, file sharing, finance, and a
host of custom applications specific to departmental needs. Its dispersed corporate network is secured using a
combination of industry standard firewalls, perimeter networks, and point-to-point connections. Because of legacy
security concerns, employee use has been restricted to onsite access and limited VPN connectivity. Outside of normal
employee channels, Fabrikam Industries has met with limited success in integrating external clients, partners, and
contractors into the existing architecture.
In an effort to decrease training investments and their infrastructure management impacts, Fabrikam Industries has
decided to consolidate its information worker Web interface onto a single platform. Specifically, the information
technology (IT) team proposed a directed effort to bring the central data center and all branch offices onto a Microsoft®
platform. From a directory perspective, if there is not a trust relationship between the domains, it makes the
deployment a challenge, but with LDAP, Microsoft ASP.NET pluggable authentication, and membership providers, these
challenges are able to be overcome.
During the next phase of scoping, the corporate intranet was identified as the next target for migration. The current
intranet principally consists of a collection of news items, employee directory, corporate events, and links to content
that resides on departmental file shares. Most changes require an IT request and a two-week lead-time.
After completing a discovery process that included stakeholder interviews and whiteboard sessions, it became clear that
one site would not be sufficient for the needs of the organization. Specifically, integrating external users into the internal
environment and Microsoft Active Directory® directory services brought concern from several departmental
stakeholders. The outcome of this was that there needed to be an intranet portal site as well as an extranet
collaboration portal site where clients, partners, and vendors could access project specific materials. High-level goals
were as follows:
• Provide a centralized location where users and managers can quickly locate corporate data critical to daily job
• Provide employees with a simple user experience that requires minimal training and is consistent throughout
organizational departments and platform feature sets.
• Ensure that the corporate brand and culture translates into a standardized user experience.
• Provide users with a rich search interface for returning content and metadata, not only from within the document
store but from external resources as well.
• Reduce IT workloads by providing powerful common management interfaces for content and organizational owners.
• Enable enterprise account authentication and user-managed authorization to corporate resources from inside or
outside physical offices.
When planning for a Microsoft Office SharePoint® Server 2007 deployment, some of the first considerations should
include site topology, also known as taxonomy or site hierarchy. How your organization will best traverse your site and
locate its content contributes greatly to a sense of location and in turn increases the perception of usability. A well-
planned topology based on corporate work chains can prevent issues later where organic growth erodes usability.
Considerations when planning should include corporate structure, stream of work within the organization, security, and
Tip: Site collections, sites, lists, and items are native security boundaries. Similar to the Windows file system, each child
inherits from the security of its parent, unless assigned differently. The most effective containers for managing security
remain sites and lists that take advantage of security inheritance. While discreet security may now be assigned to
document or item-level data, this should be considered carefully as it requires an additional level of vigilance to ensure
the appropriate assignments. These basic security concepts typically play a significant role in shaping site topology
where site hierarchy based on existing Active Directory groups can leverage existing security implementations.
Taking this into account, an enterprise typically organizes site hierarchy by departmental structure and then
departmental functionality. For example, a hierarchy may appear as Corporate Portal Site >> Human Resources >>
Benefits. This approach works for most organizations small and large and is shown in the following diagram. A
standardized hierarchy such as this provides not only a logical approach for users when browsing the portal site for
content, but most likely mirrors existing security groups within the organization. As these clear organizational units, such
as departments, are delegated control of their own site structures, they assume the management burden from IT
resources. This ownership and freedom to customize their own environment can serve as a major catalyst in
departmental and user acceptance.
An Office SharePoint Server 2007 Web application is the topmost Office Server 2007 object within the hierarchy and the
native container of the topmost site collection. Each Web application designates the primary content database for the
child site collection. The default Office SharePoint Server 2007 Web application is representative of a specific Microsoft
Internet Information Services (IIS) Web site, and because of this defines a specific IIS application scope. This entitles each
Office SharePoint Server 2007 Web application to its own Web.Config file and host header definitions. A Web
application has no visual presentation within the user interface and it is in no way visually apparent to the end user.
Human Resources Sales IT
In the case of Fabrikam Industries , which must support Office SharePoint Server 2007 users located on different
continents as well as users who speak different languages, additional complexities apply. For more information about
multilingual deployments, download the white paper Plan for building multilingual solutions by using SharePoint
Products and Technologies (http://go.microsoft.com/fwlink/?LinkId=79322). When the distance between a hosted
Office SharePoint Server 2007 site and the end user allows for adequate bandwidth and latency, a single corporate
instance of Office SharePoint Server 2007 can be more than adequate. As a rule of thumb, if a user can gain reasonable
access to retrieve and save acceptable document sizes, then location need not be a concern as with most offices located
within the continental United States. Apart from basic accessibility, geopolitical concerns such as localized working
groups or governmental boundaries may insert themselves as requirements. If a company has headquarters in
Washington, D.C., but also maintains offices within the borders of New York, then it may make sense to break off that
working unit into its own sub-hierarchy, as shown in the following diagram. This allows for more freedom within that
working group, where different rules and team members may apply.
Human Resources Sales
Human Resources Benefits Personnel
Tip: Any Office SharePoint Server 2007 Web application can be extended into multiple zones. Extending a Web
application to additional zones allows users to access the same Web site through separate and independent URLs, each
with its own Web.Config file and IIS application scope. Each zone is configured with its own load-balanced URL (protocol,
host header, and port). This allows, for instance, one Web application to make use of many configurations including
multiple authentication stores, caching scenarios, content databases, or custom HTTP modules.
Not all Fabrikam Industries locations enjoy the access to bandwidth that the United States headquarters does;
consequently, other locations may require a separate solution. In this case, Fabrikam Industries stakeholders decided
that hosting an additional instance of Office SharePoint Server 2007 at the office in Beijing was the only option that
satisfies the requirement for reasonable access to retrieve and save files. When implemented, this branch Office
SharePoint Server 2007 instance was connected to its parent site at the corporate headquarters. Administrators of both
locations must coordinate access to allow both parent and child sites to index the other’s content accordingly.
Tip: Separate portal site instances may be linked in a parent-child relationship by designating a portal site connection
from the Site Collection Administration section of the Site Settings page of the top-level site in the child Office
SharePoint Server 2007 instance (see the following figure). The advantages of such connections are limited and may not
offer enough benefit in your instance to apply.
When connected, content from the child site will be added to the parent search scope as well as set the corporate portal
site as the root for child.
After this connection is made, navigation points from the parent portal site down to the child portal site must be added
manually. There are several approaches, including: adding links within the portal site’s global navigation; links within the
current navigation of a subsite; or links embedded within portal site content, such as link list Web Parts. Since Fabrikam
Industries must accommodate a number of branch portals sites, an approach must be employed that does not
overwhelm the navigation of the entire corporate site collection. At Fabrikam Industries , it was decided to include a
static link from the corporate departmental subsites to their branch siblings by adding site URLs to a dedicated link list.
In this case, a link from the corporate portal page was added for the Beijing portal page and, where appropriate, the
same was done for departmental subsites. This can be seen represented as dotted lines in the international topology
Tip: Planning and architecture for Office SharePoint Server 2007
Human Resources Sales
Languages in and of themselves are not functional limiters when planning a hierarchy, as each individual Office
SharePoint Server 2007 site maintains discreet language control. Peer, child, and parent sites allow for language
templates at any point of site creation within the site collection. In this case, Fabrikam Industries ’ United States-based
headquarters enforces the exclusive use of English, while the Fabrikam Industries Asia Web site hosted in Beijing allows
for a mix of Traditional and Simplified Chinese, Japanese, and Malay.
Office SharePoint Server 2007 supports languages through most major features within the application. Each site, site
template, and MySite can be created in its own language when configured. When several languages will host the same
site structure, variations may be implemented that allow an author to not only designate the primary language of a site,
but also to mirror content for translation into another language. These variations of sites can be created for a variety of
reasons, but note that this functionality is only available to Office SharePoint Server 2007 deployments. While the site
creation process can be accomplished per location, the user interface is in one language. However, this page can easily
be modified. Translation is not performed automatically, but can be configured to route through a workflow to assign a
task to translate the content. This same functionality applies to lists and document libraries, so the data across the site
becomes fully available on the site variations.
Tip: Site collections are the native containers of Office SharePoint Server 2007 sites. Each Office SharePoint Server 2007
Web application initially hosts a single site collection. Each site collection contains a single top-level site that in turn may
contain any number of child sites. The top-level site collection in a Web application may contain site collections through
the use of managed paths.
Each site collection enforces specific feature and security boundaries that cannot be inherited or discovered by a parent
or child site collection. Features that are bound within a site collection and cannot be shared include global navigation,
branding, security groups, content types, content sharing Web Parts, site aggregation Web Parts, usage reports, alert
management and workflows. When attempting to make changes across multiple site collections such as deployment of
Web Parts, content types, security changes, branding, and so on, use features to package the functionality that you
desire. These features can either be activated automatically as the feature is deployed or activated on-demand by the
site administrator. Solution deployment packages can be used to bundle features, Web Parts, assemblies, and pages.
Rather than changing the site definition, which requires maintenance and complexity in upgrade, a solution deployment
package can easily be deployed or removed, making it a great choice for consistency and ease of management.
What site collections do well is provide a well-defined security boundary and ease of portability. A site collection is really
the unit of ownership, quota, and security management. Although site collections provide a boundary, they are an
important aspect of deployment in relation to performance and management. Site collections can be backed up and
moved into different content databases within the same Web application, but sites cannot. Your SQL team or storage
manager may have suggestions for database sizes. Fabrikam Industries determined that 100 GB was the maximum
database size for their top-level portal site collection as a best practice, taking into consideration manageability and
backup restore and to avoid database blocking for long-running operations. All other department or division-level site
collections were limited to a 15 GB quota, or moved into dedicated databases with 100 GB, again as the maximum
database size. It was a compromise between the SQL team and the operations team, as well as design considerations for
the information architecture. An existing site collection can be moved in its entirety to a new Office SharePoint Server
2007 Web application or server through simple backup and restore.
Now that Fabrikam Industries has divided its enterprise topology among geographies, corporate and local hierarchies
could be treated as independent instances where each locale could deploy its own topology. As project discovery
progressed, more than a few stakeholders indicated a need to protect entire department sites from non-departmental
access. While it was demonstrated to all stakeholders that individual sites, document libraries, and lists could be
individually secured, it was made very clear that several departments required more autonomy in automation,
workflow, and structure. Stakeholders agreed that those departments with specific concerns would be required to
maintain a corporate departmental site that provided all employees with unsecured content, while also maintaining
their private departmental sites only available to departmental members. This resulted in the topology below.
Office SharePoint Server
HR Corporate Corporate
Private Private Private
HR Sales IT
Site Collection Portal Site Database
In this diagram, you can see the outermost container representing the single Office SharePoint Server 2007 Web
application hosting the site instance. The root site collection and topmost site represent an enterprise portal site
template that will serve as the corporate home page and destination site. This topmost site is managed by corporate
communications team members who hand-select audience-appropriate content for the home page. From this point on,
each department takes ownership of its own site. However, it is important that corporate branding remains consistent
throughout the portal site. It was for this reason that specific site templates were created for both corporate
department sites and private department sites. This ensured that the colors, logos, and other branding elements would
remain under the control of the portal site administrators, even though each department would have explicit control
over its content.
The Human Resources department, maintaining stringent security concerns, also intends to automate much of its
personnel forms. The previous decision for independent security, which included a private site for the department and
independent forms automation with the corporate department site, necessitated the need to include the whole of
Human Resources within a single independent site collection. While this resolves Human Resources security and
automation requirements, it does complicate branding deployment and navigation where this content does not cross
site collection boundaries. These issues are explored more thoroughly later in this document.
The Human Resources corporate site will host employee manuals, payroll forms, and personalized benefits information.
Microsoft® Office Forms Server 2007 automation will collect expense, time-off requests, and other employee processing
data, then transmit that information to the departmental private site.
Sales department stakeholders determined there is little in the form of documented requirements, and expressed no
need for site-level security. However, these stakeholders opted for both a corporate and private site to maintain
consistency in the hierarchy. Sales goals and sales pipeline status would be provided by means of an executive
dashboard format on the corporate departmental site, while client sales contracts and processing would be protected
within the departmental private site through standard site-level security. Sales, which included the development of
marketing materials, easily required the largest amount of storage both by number of documents and by way of
contacts, as well as sheer document size of high resolution marketing materials.
Information Technology department stakeholders did express an interest in securing and maintaining discreet control
over internal departmental documents, but voiced no concerns over maintaining any security at all over the corporate
department site. Plans included a support ticket system maintained in the corporate department site and daily
management content within their private site.
This completes the topology for the Fabrikam Industries corporate intranet. Departmental stakeholder requirements
have been gathered, prioritized, and scoped. However, this is only the foundation and much remains to be done.
Corporate branding and user interface are the next step in a process that will enable the planned topology to finally be
built and deployed. After branding is complete, metadata planning will assist Fabrikam Industries in defining global
content types and workflows.
Branding and User Interface
Fabrikam Industries, as an organization, is invested heavily in creating strong brand awareness in its market segment. Its
corporate logo and unique color palette are closely associated with its excellent reputation and one-of-a-kind product
line. This brand identity is not only external, but is a critical part of the employee culture as well. Of paramount
importance to stakeholders is that brand identity span to all corporate applications. The corporate Office SharePoint
Server 2007 site must communicate the corporate presence and leave no question in the user’s mind that this is a
Fabrikam Industries ’ Web property.
As with many enterprise organizations, Fabrikam Industries has made a significant investment in print medium through
marketing and advertising. However, little of that investment translates into the digital presentation. When applying a
corporate brand to a Web presence, it is not realistic to expect that a print style guide will translate directly to an HTML
interface. It should be emphasized that HTML supports neither the rich text control of print, nor lavish images when
limited bandwidth and down-level browser support are requirements. Organizations where branding is considered a
priority typically maintain an in-house design staff or outsource this task to a design group. It is the designer’s
responsibility to take the overall marketing plan and design guide into account when composing a customized Office
SharePoint Server 2007 Web interface.
It’s important to differentiate print design skills from Web design skills. If print designers are not experienced in
designing for Web interfaces, an overview of HTML as a design medium will prevent what can become significant design
disconnects later on in the project. Some visual designers might be fully capable HTML and CSS developers, while some
will pass off this task to a dedicated developer. You will most likely find that your information workers and Web
developers can be very helpful with this phase, and should be included early in the process.
After an interface team has been identified, it is best to familiarize everyone with the new Office SharePoint Server 2007
controls and Web Parts that are available. While ASP.NET 2.0 functionality plays a significant role in how branding is
deployed, Office SharePoint Server 2007 navigation, search controls, and Office SharePoint Server 2007 themes will be
critical in how a customized look and feel are applied. After you are familiar with these components and controls, review
the out-of-the-box site layout as it currently exists. In many cases, out-of-the-box master page functionality is robust
enough to warrant only minor cosmetic changes, such as those to colors and headers. When more significant
enhancements are dictated by requirements, consider beginning with wireframe mockups before fully developing
graphic compositions or screenshots. This allows for strong functional validation before visual presentation overshadows
features. Beginning development with impressive graphics compositions prior to functional wireframes may act as an
easy selling tool for management, but often generates functionality requirements that are not requested in discovery
and can significantly extend the level of effort in this phase of an Office SharePoint Server 2007 rollout.
Tip: Office SharePoint Server 2007 provides a true blank slate approach to branding, where most of the user interface
may be completely redesigned to a detailed design requirement. ASP.NET 2.0 master pages allow for a globally applied
template background to all of the Office SharePoint Server 2007 user and administration screens. By modifying or
creating your own custom master page by using Microsoft® Office SharePoint® Designer 2007, unique visual presence
and functionality can be achieved.
An example of a basic wireframe mirroring the functionality of the out-of-the-box functionality is shown in the diagram
below. This breaks down functionality to its most basic component on a page.
Home Link User Menu
Site Title and Logo Search
After the wireframe is drafted and its end-user functionality is validated, designers can apply branding and visual
treatments to the interface. Visual compositions may go through several rounds to ensure that visual design, functional
design, and stakeholder intent match. In fact, this phase should be carefully managed, because visual presentation is
one of the few areas where the deliverable is so strongly based on personal perception that it is often difficult to compel
all parties to agree.
Tip: Previous versions of Microsoft SharePoint Products and Technologies (Windows SharePoint Services and Microsoft
Office SharePoint Portal Server) stored file modifications on the server’s physical file system. Artifacts such as style
sheets, templates, pages, and other files that were modifications of template files became physical changes to files on a
drive. This created several complications, not the least of which included backup scenarios and farm deployment.
Office SharePoint Server 2007 dramatically revamps this concept by moving out-of-the-box, custom, and modified assets
completely into lists. Now user interface graphics, cascading style sheets, page layouts, and master pages are all
contained in lists and are therefore in a content database on your back-end systems. This brings with it the added
functionality of workflow approval, versions, automatic deployment, and fully inclusive backups. All of these
administrative or public lists can be easily accessed by using the Office SharePoint Designer 2007 interface when
managing layouts, master pages, or cascading style sheets.
While you might not migrate your enterprise to the 2007 Microsoft Office system by using the same timeline as your
Office SharePoint Server 2007 deployment, you will need to identify those users who perform design and workflow
management tasks to receive Office SharePoint Designer 2007 during the deployment phase. This will not require the
entire 2007 Office suite, but most of the new applications are complementary and an Office SharePoint Designer 2007
end user will gain productivity by installing all of the 2007 Office system in parallel.
Microsoft Office FrontPage® 2003 is not compatible with Office SharePoint Server and cannot be used for this
Introducing Microsoft Office SharePoint Designer 2007
Get started with basic site customizations
Customizing and Branding Web Content Management-Enabled SharePoint Sites
After the combined functional and visual design is finalized, information workers will begin to incorporate the approved
branding as new or modified master and layout pages. An information worker’s primary tool for branding is Office
SharePoint Designer 2007. Through this environment, ASP.NET 2.0 master pages, Office SharePoint Server 2007 layouts,
and cascading style sheets (CSS) can be edited by either the developer or designer. While it is true that Office SharePoint
Designer 2007 is the replacement to FrontPage 2003, it is better to consider Office SharePoint Designer more as a
successor than an upgrade. A combination of Web editor, Microsoft Visual Studio® 2007environment, and rich client,
Office SharePoint Designer 2007 as an application is the true developers’ interface for Office SharePoint Server 2007.
The Office SharePoint Designer page editor interface now more closely resembles a development environment than a
Web editor, and directly supports ASP.NET 2.0 controls and Microsoft .NET script block coding. A split-screen interface
allows for simultaneous drag-and-drop design as well as code view editing. Selecting a control element in either the
design or the code view enables the Tag Properties and CSS Properties task panes with Visual Studio 2007 styles
property grids. Other task panes, such as the Data Source Library, allow the designer to browse entire site lists as unique
data sources and simply drag dynamic list-driven data onto a page. The depth and richness of this tool requires a
learning investment on the part of the designer to fully explore and understand its capabilities.
Typically, when a third-party or custom component like a server control or Web Part is installed on the server, it cannot
be rendered on the Web designer’s application, because the designer’s machine is not aware or licensed for the server’s
add-ins. Office SharePoint Designer 2007 actually queries the available functionality and add-ins with the currently
attached site and then tailors its own features based on this information. In the case of the Toolbox, a complete list of
controls and Web Parts for the current site appears. When those controls are employed in a master page or layout, they
render properly in the editor interface of Office SharePoint Designer 2007 in a manner that is consistent with the Visual
Studio 2007 designer, even though there are no add-in assemblies installed on the Web designer’s desktop machine.
This functionality extends deeper by providing page and content fields derived from the content type assigned to the
current page layout. This enables an author, through a simple drag-and-drop action with these field controls from the
Toolbox onto the page layout, to access contextual and content data without the need for manual control creation. After
this is set, rich content and metadata can be used throughout a page for viewing or editing.
When crafting a new interface within Office SharePoint Designer 2007, a key formatting component will include the
management of cascading style sheets (CSS). A subset or complimentary standard to HTML, CSS allows for inherited and
centralized application of branding. Arguably a specialty in its own right, CSS plays a major role in how visually
compatible a site may be across different browsers. How different versions of different browsers render an interface
depends greatly on how cascading style sheets have been implemented on top of and throughout the HTML layout.
Older versions of these browsers can be much less complete in their standards implementations and will not recognize
more advanced features. A down level experience should be addressed when taking advantage of richer features. From
the Authoring tab of the Page Editor Options, an author can set the specific HTML and CSS schemas targeted for a site.
Office SharePoint Designer 2007 directly addresses this challenge by natively integrating CSS development into all
aspects of the Page Editor interface. Office SharePoint Designer enumerates each style sheet referenced by a master
page, page layout, or ASP.NET control and presents them all for review and editing within the Manage Styles task pane.
Developers will find this functionality extremely useful.
Every style is editable by automatically duplicating core and theme styles into the local site or site collection list libraries
when edits are necessary. This enables designers to modify or override any formatting within the Office SharePoint
Server 2007 domain. Because of the versioned power of lists, changes to styles can be rolled-back to previous versions
without affecting the site. Bear in mind that even with these new tools, CSS development is a specialty, and with
complex issues like CSS importing and overriding inheritance, ensure that you use experienced Web developers to get
the best results for your site.
When branding and user interface are applied to a SharePoint site, they is done using native ASP.NET functionality called
master pages. Master pages are a relatively new concept to ASP.NET 2.0 and function as a background template for
other .aspx pages in a Web site. This is a very powerful concept and one that allows sweeping global changes to be
applied across a site. The diagram below provides a simplified view of how common functionality, such as search and
navigation, is included within the master page and combined with an .aspx page layout to present a single experience to
the end user.
Master Page .aspx Page Layout Rendered SharePoint Site Page
Logo Search Logo Search
Global Navigation Global Navigation
+ Content + Content
WebPart Zone WebPart Zone
Fabrikam Industries stakeholders had decided that the existing Office SharePoint Server 2007 branding was so different
from the desired corporate look and feel that it would be best to begin with a new master page and apply branding
there. Two techniques for this approach were considered, one by creating a new and truly empty master page, and later
adding controls as needed. The second approach begins by copying an existing master page and then stripping away all
HTML formatting and CSS styles to create a fully functional blank slate. In this case, the second approach was selected in
favor of maintaining the existing functionality and applying a new look and feel from the corporate brand. This exercise
of stripping away formatting was minimal and allowed for a unique HTML layout, as well as for a completely new
Fabrikam Industries cascading style sheet.
How to: Create a Minimal Master Page
Customizing SharePoint Sites and Portals
Customizing the Menu Control—in Office SharePoint Server and Windows SharePoint Services
Fabrikam Industries ’ most significant change was applied when it modified the existing navigational fly-out menus to
better suit the design compositions. Once again, leveraging ASP.NET functionality implemented inside Office SharePoint
Server 2007 and out-of-the-box navigation controls allow for significant interface change through control template
Seen below in the Office SharePoint Designer 2007 Split View mechanism, Fabrikam Industries needed to implement a
stylized tab look to its global navigation. Here, a Web developer can create a simple or complex template to render rich,
stylized UI without the need for third-party controls.
Tip: When modifying navigation, something as simple as the HTML below is the start to creating a fully customized user
interface. From this basic template, rich, branded navigation can be created to meet the needs of most interfaces.
<a href="<%# Eval("NavigateUrl") %>">
<%# Eval("Text") %>
A working understanding of HTML is necessary, but the skill sets required of most Web developers will be enough to
craft a genuinely compelling look and feel. Developers will want to leverage all the dynamic properties available by
reviewing the complete list of MenuItem properties. Additional property values such as Selected,
SeparatorImageUrl, and Target will allow a developer or designer to create very dynamic behaviors using data
provided from the out-of-the-box Office SharePoint Server 2007 navigation management Web screens.
Assets and Artifacts
During the branding phase, it becomes necessary to integrate custom artifacts and other assets including images, .aspx
pages, CSS files, and even scripts into the Office SharePoint Server 2007 environment so they are accessible to the end
user. Because most enterprise deployments provide for availability by farming Office SharePoint Server 2007 across
multiple front-end Web servers, these assets must be deployed across the entire farm for use. For this reason, it is best
to save all assets to a SharePoint list within the site collection. Whereas content images and assets can easily be stored
in standard image or document libraries, user interface assets are slightly different in that only a designer should have
access. Additionally, it is likely that such user interface assets are unique to the language of the site. Created to store
interface files, the site collection style library is ideal. This specialized list will allow you to separate branding from user-
managed assets. More importantly, this list will create a mechanism to manage interface assets for multiple languages
implemented within the same site, which are known as variations.
Because Fabrikam Industries’ branding is deployed through a combination of master pages and layouts, these assets are
maintained within a site collection boundary. For each nested site
collection to assume the branding of the parent, all graphic
elements must be copied there. This is not a straight-forward
operation, because master pages are stored within the master
page gallery, while graphic and CSS assets are stored within the
style library by variation. Site collection administrators must take
great care when developing a deployment methodology to
address this. Scripts, Office SharePoint Designer 2007 packages,
or simple export and import tasks for individual elements can be
used, but no one option could be called ideal for all
environments. When automation is paramount, then scripting
these deployments is useful for complex repetitive tasks. Export
and copy scenarios are simplest for one-off or changing scenarios.
A combination of the two will most likely be necessary to
promote branding in a production environment.
Metadata, Content Types, and Enterprise Search
Office SharePoint Server 2007 is a document and record repository. At its core, lists and document libraries hold content
for versioning and retrieval. While application-based storage is not unique, this becomes a compelling environment in
which business users can tag and retrieve the data they need quickly and easily. Office SharePoint Server 2007 provides
many ways to access content but certainly encourages users to browse or search for what they need. Once again, this is
not a wholly unique feature set, but the advantages gained from items and data stored within Office SharePoint Server is
very useful when metadata relevancy can be used without the need for configuration.
Metadata allows an author or other user to attach supplemental information to a file or document without affecting its
contents. These types of data are commonly available for documents stored within a file system by recording fields such
as Created Date, Modified Date, Read Only, and Hidden attributes. Office SharePoint Server not only stores these file
state data, but also allows for any number custom fields defined by the list owner. In much the same way that Windows
allows users to sort and group files listed in Explorer, Office SharePoint Server moves this concept significantly further by
allowing for saved views whereby customizable display styles allow users to filter, sort, group, limit, and total SharePoint
list contents based on metadata criteria. This is an immensely powerful concept when looking for a type or category of
document within a much larger set. Not only does metadata apply to browsing and views, but to search as well. In fact,
search utilizes metadata not only for sorting and filtering as you would expect, but also as its basis for search result
The most fundamental unit of storage in Office SharePoint Server 2007 is a list, which is a container based on rows and
columns, much like a database table. Each row represents a single record and each column represents a unit of
information available for each row. The advantage of lists over (SQL) database tables is that a SharePoint list is
completely managed by an end user or site owner through the Web interface. No technical assistance is necessary to
create, customize, or assign user privileges to a list. There are many predefined list content types that provide
specialized functionality to the end user. Among them are document libraries, contact lists, a calendar, picture libraries,
slide libraries, and custom lists. The most common is the document library where each row stores and versions an
individual document and can even synchronize to a user’s desktop through Outlook 2007.
Every column in a list is considered metadata, and is available for use throughout most features in Office SharePoint
Server. All available list types include predefined columns and allow for additional owner-defined columns. The following
table shows basic list metadata types.
Metadata type Description
Single line of text User provides a single line of fixed text with a maximum length.
Multiple Lines of text User provides one or more lines of rich text that can be formatted.
Choice User selects from a predefined list of options in the form of a drop-down box, radio button list, or
(Menu to choose from) check box list. Fill-in answers are optionally allowed by the owner.
Number (1, 1.0, 100) User supplies a numeric value within the numeric ranges specified by the owner. Calculated values
Currency ($, ¥, €) User supplies a numeric currency value within the decimal and value ranges specified by the owner.
The national currency is selected by owner.
Date and Time User supplies a date or date and time as specified by the owner. Calculated values may be set by
Lookup (information User selects from a predefined list of options in the form of a drop-down box, radio button list, or
already on this site) check box list. Available options are derived from SharePoint list data on the same SharePoint site.
Yes/No (check box) Users provide yes or no data by checking or clearing a box based on the title and description
Person or Group User selects from a predefined list of users. Owner specifies by which criteria the list of users is to
Hyperlink or Picture User provides a valid URL and optional text label or image path to serve as the link body. Owner
selects whether the user is to specify URL or image data.
Calculated (calculation A calculated column is read only and presents information to the user by manipulating existing list
based on other data into a required format. This formula may concatenate text data or calculate a mathematical
columns) formula to achieve its result.
Business Data User selects from a predefined list of options. Available options are derived from Business Data
Catalog selected by the owner.
Content types do not store data as a list would, but describe the properties of data, and are considered the basic level
for describing content. A content type may have many properties, termed content columns, and each column may be of
a data type included earlier in the lists section. There are many pre-defined content types for each site collection, and
administrators may change or create additional content types as needed. Just as .NET interfaces in application
development support inheritance, each content type inherits from a parent content type. Thus, a child assumes all of its
column types. For example, if the content type Item includes columns A, B, and C, then the content type Document,
which inherits from the Item type, will also include columns A, B, and C.
In fact, one content type or another describes every item stored within a SharePoint list, and each list or list type may
have one or many content types assigned. A list inherits the content columns from all the assigned content types, which
appear as list columns.
The following table shows special content column types not immediately available to lists. These special content types
are associated with the Publishing feature.
Column type Description
Full HTML content with Intended for Enterprise Content Management this type allows for complete control over HMTL
formatting and content including referenced image and document assets. Discreet control over HTML content can
constraints for be set when placing content field controls within SharePoint page layouts.
Image with formatting Intended for Enterprise Content Management, this type allows for a single image reference and
and constraints for browsing assets within existing image libraries. Discreet control over images can be set when
publishing placing content field controls within SharePoint page layouts.
Hyperlink with Intended for Enterprise Content Management, this type allows for a single URL. Discreet control
formatting and over HTML content can be set when placing content field controls within SharePoint page layouts.
Summary Links data Intended for use in Enterprise Content Management layouts, this type allows for a bulleted content
supplied by the authors without the need for a dedicated list to populate data. Discreet control over
summary links behavior can be set when placing content field controls within SharePoint page
After metadata are defined and populated, they become accessible within not only the lists and views themselves, but
are also available and searchable throughout the SharePoint site. A user that is not browsing for content is most likely
searching for metadata. The basic search box control located by default on every page of a SharePoint site uses
keywords to document not only its content but through metadata as well. As search, this is an effective approach to
locating documents, but it cannot always provide the discreet focus a user needs. To accommodate additional control,
search allows for ad hoc metadata filtering by allowing the user to include or exclude specific keywords by global
content type columns. Shown in the screenshot below, three properties have been selected from available content
columns. This substantially focuses the scope of a keyword search to very specific criteria and can provide for much
more successful results when searching through thousands or tens of thousands of documents.
After an extensive discovery and stakeholder review of document use and email attachment traffic, Fabrikam Industries
decided that in order to effectively use Office SharePoint Server 2007 for its content, it needed to filter and group its
documents by department ownership and assigned fiscal year. Requirements included the following:
1) Fabrikam Department must collect metadata as a multi-select drop-down box that includes the values Human
Resources, Operations, Information Technology, Sales, and Executive Staff.
2) Fabrikam Fiscal Year must collect metadata as a multi-select drop-down box that includes the values 2005, 2006,
2007, and 2008.
3) Fabrikam Department and FabrikamFiscal Year are required fields. Required fields must be enforced within the
user interface so that the author must populate data.
4) Both Fabrikam Department and Fiscal Year must be searchable.
5) All documents must use the Fabrikam Department and Fabrikam Fiscal Year fields.
Based on these requirements, it was decided that both fields needed to be site columns so they would be available to
enterprise search, and then added to the document content types so that every document in the site collection would
require these specific metadata. The group briefly considered creating a custom list template that would include these
two columns locally in the list, but this design was ruled out as there were too many ways to circumvent the
Adding these metadata to the site collection begins by selecting site columns from the Site Settings page of the topmost
site collection. The Site Columns page displays a long list of columns already available within the site collection. Creating
a new column appears much like adding a new local column to a list. For the Fabrikam Fiscal Year column, the Choice
data type was selected, which allowed for the manual entry of the values 2005, 2006, 2007, and 2008. You will notice in
the column screenshots that within the Group section, New Group was selected and labeled Fabrikam. This separates
the new columns within the master list into their own section. Also note that the Require this column contains
information has been checked so that that it cannot be left blank by the author.
When adding the Fabrikam Department column, it was decided that that the department options would be more
volatile than Fiscal Year options, so a Fabrikam Departments list was created in the portal site. Each department was
added to this list. When the Fabrikam Department column type was added, the Lookup data type was selected, which
allowed the new list to be identified as the source for the department options. This now allowed other end users to
manage the option data through the new departments list, rather than the site collection administrator altering the
static column data.
Plan content types (Office SharePoint Server)
Fiscal Year Global Column Type Department Global Column Type
After the two site columns had been created, they were added to the Document content type. This interface can be
located by selecting Site Content Type Gallery from the Site Settings page and adding the two new columns. Once
completed, Fabrikam Departments and Fabrikam Fiscal Year become required metadata for every document stored
within the Fabrikam Industries intranet. This can be quickly validated by selecting New Document from the menu of any
document library in the SharePoint site collection. When the document opens in Microsoft Word 2007, the two new
columns present themselves automatically in the Document Information Panel that emerges from Office (2007) Ribbon.
This interface denotes and enforces that the author must provide content for all required fields. Notice in the ribbon
screenshot below that the Fabrikam columns display the pre-populated options from both the static Fiscal Year options
and the list-driven Department options. After this document is saved, all values are sent back to the server as metadata
and stored within the correlating list columns.
Tip: Now that the two new columns have been mapped to the document properties courtesy of 2007 Office, we can
now include this data through Quick Part
Properties. From the Insert Ribbon Tab,
select Quick Parts >> Document
Properties >> Fabrikam Departments. This
inserts a dynamic field control into your
document that not only reflects the
current column data wherever it is placed,
but also allows the same data to be edited
from within the document. All these
changes are updated in the list columns
and available to search after the document
Fabrikam Industries Search
Now that Fabrikam Industries has defined and populated Department and Fiscal Year data, these metadata must be
made available within the advanced search screen. This does not happen automatically, as with the changes to the
document libraries. For this, the Advanced Search page must be edited, and the search Web Part modified to reflect the
new content columns. The search Web Part Properties group includes a Properties input field where the Web Part
behavior can be modified. A large XML block describes a list of options that include language, searchable properties, and
result fields for each searchable content type. These configurations are defined as one single fragment so it is best to
copy the entire block manually and edit it within Office SharePoint Designer 2007. Locate the property and results
elements that apply so that Fabrikam Department and Fabrikam Fiscal Year can be added, then paste this information
back into the Web Part XML block. After the Advanced Search page has been saved and published, it will allow for
property restrictions and result sets that include Fabrikam’s two new content columns, as shown in the screenshot
Tip: SharePoint lists and document libraries are a significant paradigm shift for users accustomed to the network file
shares. The most successful SharePoint deployments migrate their primary network file shares into the SharePoint
environment by using well-organized document libraries, which eliminates most (if not all) mapped drive letters from a
user’s drive. The advantages to this—such as security, auditing, versioning, search indexing, accessibility, and content
types—should be clear, but users seldom embrace this change until they have been motivated to invest in learning the
Fabrikam Industries found that content types did not traverse the site collection boundary. Any content type created
within the parent site collection is not inherited by the child site collection. For this reason, Fabrikam Industries decided
to create site templates where the content type modifications were already present and these templates would provide
the foundation for all subsequent site collections. If any updates are needed to the existing content types, Fabrikam
Industries will use solution deployments packages to make the necessary changes.
Microsoft Workflow and ECM starter kits accelerated deployment and understanding. Fabrikam Industries planned to
create and use custom-created workflows only on knowledge repositories and use the out-of-the-box workflows with
Office SharePoint Designer for most cases.
Deploying a Solution
Enterprise Content Management Starter Kit and Requirements Authoring Starter Kit
1.1 Enterprise Integration
It is safe to say that today Office SharePoint Server is not the single repository for all enterprise data. There will continue
to be a wealth of data spread throughout large and small organizations on different platforms. Structured data that
resides in applications such as CRMs, ERPs and proprietary systems based on flat file, relational and OLAP data
structures are prime candidates for Office SharePoint Server integration. The strength of Office SharePoint Server will be
in acting as the integration point into this data by presenting it in a format accessible to the entire organization, not just
those with the appropriate trainings or desktop applications. Addressing this need of external application data, Office
SharePoint Server 2007 Enterprise edition introduced the Business Data Catalog. The Business Data Catalog is an open
interface for internalizing foreign application data by mapping ODBC or Web Service interfaces into Office SharePoint
Server. Through standardized XML, configuration files, tables, views, stored procedures, Web methods, and entity
relationships can be defined for use natively within Office SharePoint Server.
Core features for the Business Data Catalog include:
a) Read access of external data stores.
b) Data or SharePoint tier security delegation for individual data entities.
c) Indexing and retrieving data through SharePoint Search and dedicated search scopes.
d) Drag-and-drop Web Part access to Business Data Catalog entities based on user rights.
e) List and content column integration.
f) Supplemental user profile data.
Every connection from the Business Data Catalog to an external data source is defined as a Business Data Catalog
application. Each application exists as a collection of nested structures that include applications, entities, and methods
and actions. Applications contain one or many entities and entities contain one or many methods and/or actions. Office
SharePoint Server 2007 does not provide a user interface for the configuration of an application, but does require a
detailed XML application definition. Due to the complexities of XML and application data structures, the creation of this
definition typically requires a savvy information worker or experienced software engineer. Partners have created tools
to make the creation of these definition files easier.
Application Serves as the definition and boundary for the connection to a single data source. This level stores
connection string or location data for databases and Web services. Normally, user account information is
passed through to the data store, but fixed account log-in information can be provided here if it is
desirable for all users to access a repository using a single user account.
Entity Can be characterized as a single two-dimensional data structure analogous to a relation data table or
potentially more abstract such as a Web method result set.
Method Analogous to an API method or Web method and defines specific get and set functionality for retrieving
and sending data. Office SharePoint Server 2007 requires specific flagged methods for record and search
interaction. These methods may include embedded SQL statements for querying data or may leverage
existing stored procedures depending on the availability within the source data store.
Action Provides a means to exercise some sort of functionality on an entity record. For example, a Business Data
Catalog entity record returned as part of a Office SharePoint Server search result set requires a link for a
user to obtain more detail about that search result. A Business Data Catalog action provides the
mechanism for Office SharePoint Server to insert a custom URL that will provide that data. One of the only
Business Data Catalog options configurable using the SharePoint Service Provider interface, action URLs
can include query string or form header data based on individual Business Data Catalog fields so that
requests may include state full information necessary for record retrieval in an entity detail page.
The Business Data Catalog is considered to be a Shared Service Provider (SSP), and is managed through the SharePoint
Central Administration Shared Services Web site. After the application definition has been uploaded, the structures of
the application can be viewed and validated from this interface. If the required authorizations are not accommodated by
the external data store or additional SharePoint-level security is necessary, permissions can be assigned through this
interface on an application or entity level. This allows an application to be tested and tuned within a development or
staging environment then later deployed to a production SSP when validated and finalized.
Tip: The Business Data Catalog provides the BdcMetadata.xsd file, an XML schema definition file (XSD) that defines the
XML element mapping structure necessary for creating an application definition file. When authoring metadata using
Microsoft Visual Studio 2005, valuable IntelliSense support can be gained by copying XML definition to a working folder
and setting the schemaLocation attribute of the root element to point to this schema. The BdcMetadata.xsd file can
be located in the Bin folder of the Office SharePoint Server 2007 installation directory, typically located at
<Root>Program FilesMicrosoft Office Server12.0Bin.
Early on, Fabrikam Industries identified a relational data structure supporting its product catalog system for inclusion
within the Office SharePoint Server portal site. This application had evolved internally and worked well although order
processing, product fulfillment, inventory, and call center systems were all relegated to their own dedicated
applications. Those not directly related to these activities had very little access to product detail or pricing. It was
management’s desire to make these data available to everyone within the organization regardless of role or training.
Fabrikam Industries was beginning plans for the development of a dedicated custom Web application to perform this
task when stakeholders for the Office SharePoint Server deployment team recognized the Business Data Catalog as a
potential match for the functionality requirements. Though the original product catalog stakeholders indicated
significant complexities with the requirements, it was found that only three tables were necessary for viewing by
employees. Stored in a Microsoft SQL Server® 2005 instance, this included two navigational tables and a product detail
table. These tables (shown in the figure below) have clear relationships pre-defined. Upon review, there were no
Stakeholders in the Fabrikam Industries Office SharePoint Server solution scheduled a planning meeting with the
corporate owners of the data store. When it was surfaced that all corporate users required explicit read access to SQL
tables (though by means of a proxy) through the Business Data Catalog, there were serious concerns raised by the SQL
administrators. Intense discussions followed regarding security approaches for critical corporate data. It was vigorously
debated whether to use a single authenticated service account or a custom proxy Web service, or whether users would
indeed be granted the explicit SQL table access rights requested by the team developing the Office SharePoint Server
solution. A single user account would allow for simple integration but would treat all users with identical rights and
provide no mechanism for individual user auditing. A Web service would allow custom interfaces to intercept and proxy
requests to the data store, thereby accommodating hard perimeter network boundaries where network security is
factor. Direct SQL table access lets users’ accounts pass directly to the data store where the SQL server decides which
data is appropriate for a specific user and logs access in the process.
After weeks of protracted discussions and prototyping, it was agreed upon by both the SharePoint team and the SQL
administrators that users would indeed have specific read access to the necessary data tables. In the end, what the
prototyping found was that core application users already possessed this access at a minimum and the additional read
access for the whole of the company posed no additional threats and presented no new potential attack surfaces for the
server running SQL Server.
Tip: When developing Business Data Catalog Application definitions, the easiest approach to creating the definition is to
include all fields in the table, making them available for later use by anyone. Typically, an organization will be very
selective as to which fields are available to end users. Depending on the architecture of your application, some fields
may be sensitive or even encrypted. This can produce extended discussions on which fields are useful and appropriate
for users throughout the organization. It may be that an organization decides to create multiple application definitions
to the same data structure, one perhaps complete with all fields and one restrictive with limited field access, then
assigning specific permissions only allowing all company access to the more restrictive of the definitions.
Data resources now cleared for use, a task was assigned to an internal software engineer to create an application
definition for the tables shown above. Developing the XML definition is not a simple task, and should not be assigned to
anyone other than a software engineer. The XML relationships can be daunting at times and require a deep
understanding of Office SharePoint Server, .NET data types, SQL queries, XML, and relational data. Expect that the
responsible engineer will be subject to a longer ramp-up time than for other new interfaces. It’s advisable to execute
this phase in a development environment where the data source and Office SharePoint Server 2007 will not impact or
interact with production data.
While Fabrikam Industries originally considered this information to be freely available to anyone in the organization, it
was later recognized that clients and vendors with network access and corporate accounts should not have access to
product inventory, catalog subsets, or pricing information. Instead, they should use existing avenues for review. To this
end, these users, who are also users of the intranet, must be excluded from access to this Business Data Catalog
application. This can be accomplished by setting the appropriate application- or entity-level permissions. These rights
are assigned through the SharePoint Shared Service Provider interface. By accessing any Business Data Catalog
application or entity through the Web management pages, discreet permissions are available. Because Business Data
Catalog data is hosted within the Shared Service Provider scope, any Office SharePoint Server Web application
connected to the SSP will have access to the defined application definitions. This should be considered when assigning
Web Parts are the easiest way to surface data from the new definition. When clicking Add a Web Part on any Office
SharePoint Server page, select Business Data List and add it to the page. When first added, the Web Part properties
must be set to use an available Business Data Catalog entity as its source.
In this example, the Product Category Entity is selected. When added, it displays all fields available to the entity. For
readability, it is best to select Edit View from the toolbar. This interface is similar to a list view management screen and
will allow the configuration of which fields and rows are displayed for a user.
In the example below, the same Web Part is configured to display only the Name field and no more than five records.
For a more interactive experience, take advantage of established relations ships and connect Web Parts together. Add a
Business Data Related list Web Part and select a Business Data Catalog entity with a relationship. In fact, when using this
particular Web Part and selecting a Business Data Catalog entity, the interface only displays entities with defined
relationships. Once again, set the Edit View options so that only the name is shown and the Web Part presents a clean,
simple interface to end users. Next, using the standard Web Part Connections menu, set the Product Subcategory Web
Part to retrieve data from the Product Category Web Part. Automatically, the Category Web Part will display option
buttons for selection and, when clicked, immediately filter Product subcategory results.
Repeat the same process to connect a product entity to the Subcategory Web Part. Next, add a Business Data Item Web
Part to display the product detail. After all the Web Parts have been connected, you will have created a respectable
viewing interface useful for navigating from Category to Subcategory, Subcategory to Products, and Products to Product
Detail all with Web Parts and a single XML application definition required only once at the initial setup. This same data
can be reapplied on any page within the site collection and customized for each use.
Content types and list columns also use the very same application definition within the Business Data data type, which
will provide lookup data type functionality populated by a Business Data Catalog data source. This provides for very
powerful scenarios such as a list of departments provided by a customer relationship management system or a list of
office locations provided by a custom database. like drop-down box departments provided by a CRM system or office
locations provided by a custom database.
The final step in Business Data Catalog deployment is adding the Business Data Catalog application to the enterprise
search results. This allows the use of the existing search functionality to locate Business Data Catalog content alongside
standard SharePoint corporate document content. These sources can be included in different scopes for more discreet
control and even mapped to content types. This application can be added as a search source from the Shared Service
Provider interface by selecting Search Settings >> Content Sources >> New Content Source. This registers the Business
Data Catalog application with the search crawler and allows it to be indexed on a one-time, inclusive or independent
Plan for business data connections with the Business Data Catalog
One of the most common requirements of any system is reporting. It is usually listed as a top five must-have
requirement by stakeholders and yet seldom makes it to the final list of deliverables due to time, cost, or application
functionality. Relegated to a later phase, most reporting never happens. Office SharePoint Server 2007 arrives with
significant out-of-the-box reporting that requires little-to-no configuration.
Settings required for documents and content auditing requires no more than simple checkboxes. Found in the Site
Collection section of the Site Settings menu, Configure Audit Settings is easy to use. By selecting the appropriate
auditing levels, seen in the screenshot below, Office SharePoint Server gathers user activity data that are then available
as Excel reports from the Site Settings menu.
Information Management Policies
Where lists are concerned, an Information Management Policies can be set for each content type assigned to the List or
Document Library. This is extremely powerful in that an owner can manage policies for Document Labels, Document
Auditing, Scheduled Expiration, and automated Barcodes for discreet Content Types. If these need to be enforced across
site collections, information policies can be added to the site template or deployed using Solution Deployment packages
produced by the development team and deployed by the farm administrator. Be aware that turning on all auditing
settings across all sites can affect server performance as it will log each event.
Labels Document labels allow a policy to enforce that important metadata be printed with every document
regardless or content or author. Information such as content ownership, project, SharePoint site,
other assigned metadata is printed as part of the document. These labels may set so that they are
protected from the author or may be changed based on policy requirements.
Auditing Auditing allows a policy to enforce logging of opening, editing, check-out state, movement and
deletion or restore by content type. Each event is viewed by list-level reporting available in the List
Settings interface. This should be orchestrated so that site collection-level auditing is not duplicated by
a policy and therefore duplicates the work executed on the server.
Expiration Many times due to governmental or corporate document retention policies, an item may necessitate a
set lifespan. For example, sensitivity or archiving may require a document to be set for deletion within
seven years of the last date and time that the document was created or modified. Expiration events
may trigger a delete activity or initiate a published workflow. A workflow offers the most power and
can automate decisions for whether a document is retained, reassigned, or archived to low-cost
storage. There are many approaches offered here and all should be reviewed for options that fit your
Barcodes In order to facilitate tracking of physical paper documents within an office or system, standardized and
unique barcodes can be assigned to each document. If an existing mechanism exists within the
organization, a barcode may be arbitrarily assigned to a document for physical tracking.
Define document retention policy
Roles and Training
If it is not apparent by now, Office SharePoint Server 2007 is not merely an install-and-walk-away deployment. What
ensures its success is the people who use it. Thus, their needs should be determined well before any installation occurs.
Understanding how an organization consumes and distributes its data is critical to how Office SharePoint Server is
enabled and configured. Early in the discovery process, consider gathering representatives from across the organization
to form a stakeholder’s group. These members will be your guide not only to a successful deployment, but also to
getting the word out and generating real interest company-wide.
While the Office SharePoint Server user interface should be considered user friendly and presents a small learning curve
for anyone familiar with Web use and the Internet, remember that its new concepts and sheer number of options can
appear daunting to many corporate users who are steadfast in their use of corporate file shares. Many users are
personally attached to their corporate mapped drives. When deploying Office SharePoint Server 2007, be sure and
include a training program not only for the administrators and developers, but also the designers and information
workers. Your ability to help them understand the company strategy and vision will directly impact adoption.
When training users, consider creating a demo environment where each user completes activities in Office SharePoint
Server in an environment which mimics production. Compel users to perform role appropriate tasks such as creating a
site, creating a list, and adding their favorite co-workers to the site’s contact list. Whatever Office SharePoint Server
functionality considered core to corporate goals should be provided as a hands-on in training or many corporate users
will never explore beyond their simple own daily tasks.
As challenging as it may be at times, always consider users when planning an Office SharePoint Server deployment.
Everyone who uses Microsoft Office Word or Microsoft Office Excel® is also interacts with Office SharePoint Server.
System administrator This role is responsible for server and database management. Individuals in this role
allocate physical infrastructure, install Office SharePoint Server, provision and configure
Web applications, and provide for top-level security administration. They are also
responsible for deployment practices, SharePoint central administration, monitoring,
maintenance, backup and restore, disaster recovery, and management of Shared Service
Information worker This role configures and extends site- and list-level feature sets. This includes branding,
advanced Web Part features, workflows, and other integration points. Training should
include Office SharePoint Designer, and the Shared Service Provider interface for search or
other service management (optional); Site Settings; tools such as InfoPath and Office
SharePoint Designer; and standard SharePoint site administrator interfaces.
End users This role accounts for the majority of Office SharePoint Server users and skills will vary
greatly. Core daily use will include basic navigation, search, and document management.
Transitioning from a traditional file server-based network to a SharePoint store is a
significant paradigm shift and some users can encounter difficulty with change. Beyond
basic user interface, the focus should be on understanding lists, user interfaces, navigation,
workflows, upload, offline, and interaction with client applications.
Microsoft Office SharePoint Server 2007 provides a robust platform to create and deploy enterprise functionality with
little to no custom development. Only a selected set of features available were presented in this document and it is
recommended that additional time be set aside for research when preparing your own deployment. The most successful
Office SharePoint Server projects spend dedicated time planning and documenting with stakeholders a detailed
roadmap of features and phases for installation.
Microsoft Office SharePoint Server 2007
MSDN Guide to Office SharePoint Server 2007 Features
Office SharePoint Server 2007 on TechNet
Technical Library Office SharePoint Server 2007