Real World Case Study: Bridging the Service Gap between

Foundation and Standard Editions of SharePoint 2010

This session covers the challenges, architectural approaches, decision points, and solution elements involved in delivering a customized
collection of Standard Edition services to a client that is implementing only the Foundation Edition of SharePoint 2010. The content of
the session centers on concepts and challenges from a planning point of view and includes discussions about organizational/technical
considerations and constraints particular to satisfying business requirements (many of which are specific to the client's business
model). Due to IP rights asserted by the client, no implementation code or documentation can be distributed, but the session does
present the service interface framework that was implemented and will contain enough material to help SharePoint Developers and
Architects learn some lessons from the challenges encountered and aid in realizing the extensibility of the SharePoint and .Net API's.
The session will conclude with information regarding links to resources and tools used as part of the solution, as well as current
information about the upcoming SharePoint Saturday event in May 2010. Below is a high-level outline of the discussion points:

The Backstory: How Did We Get Here?

During initial technology discovery and POC activities in early 2010, the client became enamored with certain features available with
the Standard Edition of SharePoint 2010, specifically the MMS, Content Type Hub, and Global Term Sets. However, for a 100,000+ user
base, the license fees from Microsoft were well outside of budget estimates. Our team was then tasked with delivering an
approximately equivalent service set (via custom coding) to not only meet organizational business requirements, but also provide
additional Enterprise-level services to enforce specific governance rules, a controlled site provisioning system, and centralized
monitoring and reporting of process activities.

Business Requirements
 Emulate services found in Standard edition:
o Centralized control of metadata tagging and enforcement
o Centralized origination and control of metadata tag value sets (term sets), including default value and permission
assignments based on specific site and list context
o Centralized origination and synchronization of Content Types, Site Fields, Lists, and List Fields between source and target
sites; allow site-specific auto-assignment via ‘push’ model as well as site-specific subscriptions via ‘pull’ model
 Custom field types (with extended attributes/services) mapped to centrally managed value sets (term sets)
 Centralized Enterprise configuration values (i.e. - timer job directives, site-specific configurations, etc.)
 Enterprise enforcement of governance via Content Types and mapped custom field types
 Global Services should be discoverable and accessible by client types outside of SharePoint processes (command processes,
HTTP/Web processes, WinForm processes)
 Other requirements:
o Provide for template-based site provisioning using high-level generalized templates and ‘buffet-style’ feature activation
 Real World Case Study: Bridging the Service Gap between
Foundation and Standard Editions of SharePoint 2010
o Provide for centralized exception and event logging services
o Provide for internal permission elevation (where justified) to accomplish interactive tasks across sites and farms
o Provide for instrumentation of critical processes to allow for administrative server alerts (where desired)
o Provide list-based presentation controls to replace use of XML DataView web part
o Provide list-based menu and breadcrumb web part
o Allow provisioning, content migrations, and maintenance activities to be performed by administrators not familiar with
SharePoint

Challenges & Organizational Constraints

 Use of SharePoint Designer is not allowed in any production environment
 No native publishing or content-approval processes available; existing organizational processes and procedures take precedence
 Application and Data environments are highly segmented; strict procedural protocols are enforced
 The organization implements a detailed and process-heavy vetting protocol for introduction and adoption of third-party
components and services
 Software guidelines are well-established; governance, not so much
 SharePoint is not the established platform; user adoption is crucial
 The executive staff issued the directive, but a fair amount of SharePoint skepticism exists at the director level
 As usual, budget and time constraints apply to the first release
 Expect an extensive outside third-party evaluation of our approaches and patterns

Scope of the Service Set

 Global Services and Resources Site, including supporting SharePoint Jobs and Events
 Emulation of Standard Features (Managed Metadata Service, Content Type Hub, and Term Sets)
 Site Provisioning Model
 Page Provisioning Model
 Custom Master Pages, Styles, Jscript, and Web Parts

Architectural Approaches
Systems Design
 Emphasis on SOA approach; think high-cohesion and low-coupling
 Plan for change; it’s the only true constant in systems design
 Leverage existing framework services; don’t re-invent what’s already available
 Real World Case Study: Bridging the Service Gap between
Foundation and Standard Editions of SharePoint 2010
 Extend on existing services where possible
 Plan for eventual platform upgrades:
o Minimize one-off customizations; thoroughly justify & document if actually performed
o No modifications to system files in 14 hive!
 Emphasis on templates and features for flexibility of design implementation

Coding Practices:
 Minimize technology-specific services; avoid assumptions of certain contexts in design
 Emphasis on highly-controlled migration of releases across environments using checklists and detailed ‘move sheets’
 Emphasis on proactive, standardized coding practices; all code is ‘owned’ and directly accountable to someone
 Services should communicate to their callers robust contextual information about the result of their activities; think Custom Types
 Powershell should play a large part in provisioning, content migration and maintenance activities
 Ease of maintenance and recoverability via detailed logging and built-in ‘tunability’, ‘testibility’ and instrumentation

The Solution Set Realized

 Governance document finalized
 External audit completed
 Deployment of initial sites to production in Dec 2010
 Currently processing a flood of requests for new sites and extended services

Lessons Learned
 The .Net Framework holds a lot of surprises and not-well advertised utilities; take time to investigate the namespaces, specifically
System.Net, System.Web, …..
 Is there ANYTHING Powershell can’t do??
 When approaching technical challenges, first question should be “Has anyone already done this?”