Tuesday, October 30, 2012

New SharePoint 2013 Book: (SharePoint 2013: From the Trenches)

EPC Group is thrilled to announce a new book endeavor by our CEO Errin O'Connor and several members of EPC Group's leadership team that “Pearson Education | Sams Publishing” will be releasing, "SharePoint 2013: From the Consulting Trenches." This is sure to be the most comprehensive and in-depth SharePoint 2013 book to be released (early next year)!




 

Monday, October 22, 2012

Leveraging Themable CSS in SharePoint 2010

By Daniel Galant -  EPC Group's Director of Solutions and Services

There have been many changes and improvements with the release of SharePoint Server 2010 and how it implements a number of features and services. One of those features is the manner in which Themes are created, applied and customized in your SharePoint deployment. I came across a number of articles and posts dealing with how to create themes using Office applications, such as PowerPoint and Word. However, there were not many that dealt with the customization of your CSS through the use of the Theme Comments that SharePoint will leverage in order to apply your theme scheme to your customized Cascading Style Sheets (CSS).

This article deals with that very topic as I’ll endeavor to guide you through how to create and apply theme comments to your custom CSS so you can indeed leverage Themes in SharePoint 2010. To start off, let’s simply take a look at attaching some custom CSS to a Master Page in order to apply our own styles to the SharePoint site.

While there are several methods for attaching a custom style sheet to your Master Page, best practice dictates using the link in the of your Master Page. With SharePoint 2010 now supporting the After property, you can ensure that your custom CSS is applied after SharePoint’s core styles.

Master with attached CSS

Now we’ll also add a custom header image to the page so that we’ll be able to leverage the RecolorImage token as well later in the article.

Added Header Image

Let’s take a look at the CSS itself.

Original custom CSS

Notice the body #s4-ribbonrow setting the background-color as well as the TopHeader class pointing to our custom image. There are no theme comments added to the CSS yet, so the ribbon row color won’t be affected when you apply a theme to this site and no changes will be made to the header. Setting the new master page as our default master for the site will now render the site as in the image below.

Site Settings page with new master applied

If you then apply a theme to the site what happens? Let’s use the Vantage theme and see what the effect is.

Vantage applied no comments

Notice the changes to the TopLink, QuickLaunch and settings page, but the ribbon row and custom header remained the same. In order for these elements to also be affected by applying a theme, you must add the appropriate theme comments to your custom CSS.

In order to leverage theme comments when they are added to your custom CSS, you must first be sure to place your CSS files into the proper location within your site so that SharePoint will actually read them and apply the settings to your pages. For theme comments to be read by SharePoint when you apply a theme, you need to place your custom CSS files in a folder called Themable that you create in the Style Library of your site. This folder does not exist out of the box, nor will it be created magically for you when using custom CSS and theming.

The Style Library before:

Style Library before

The Style Library after creating the Themable folder:

Style Library after

Once you have created the Themable folder, import your custom CSS files into this location and be sure that your registration links are pointing to these files and not somewhere else in your site. Now to make your styles leverage themes when applied, you need to add the theme comments to your CSS.

There are three different tokens that can be leveraged by your CSS, ReplaceFont, ReplaceColor and RecolorImage. I’m not going to go into depth on the effects or properties of these elements here but ReplaceFont will let you change certain font elements to use one of the two available theme fonts, ReplaceColor allows you to substitute any of the 12 theme colors into your styles and RecolorImage will allow you to use any of the 12 theme colors in your images. We’ll see more on this later.

Right now we are going to add a comment so that the ribbon row will be effected when you apply a theme to the site. Since we are trying to leverage the theme’s colors to apply to the ribbon row, we’ll use the ReplaceColor token. The syntax for the comment is as follows:

/* [ReplaceColor(themeColor:”color”, property:”value”)] */

In the above comment, color represents one of the 12 theme color choices that you want to use to replace the color property of your style such as Dark1 or Accent5. For property you can use either themeShade or themeTint to darken or lighten (respectively) your color choice with a value between 0.0 and 1.0. Be aware that if you are not going to use the property:”value” option, do not include the comma in your comment. Doing so will cause SharePoint to skip your comment and you’ll be trying to figure out why your choices are not being applied.

The image below shows the theme comment added to the custom CSS file.

ReplaceColor comment added

This line simply tells SharePoint to replace the background-color #abc830 with the themes Dark2 color. You’ll now save your modified CSS and try applying a theme. Once again I used the Vantage theme. The image below shows you the 12 colors defined by this theme.

Vantage Color scheme

The result of applying this theme at this time is the following.

Vantage applied CSS not saved

Alright. So what happened to the ribbon row and the custom header we applied? Here you see the first of several issues you can run into when trying to use theme comments with your custom CSS. The site that I am working with in this example happens to be a publishing site and so the Style Library is under content approval. This means that any changes made to its files need to be published as a major version and approved before they can be properly used. Now while SharePoint seems to read and apply changes made to the CSS styles without having to go through all this, it does not process your theme comments until you have an approved major version of the file. As a matter of fact, as can be seen here, it seems to completely disregard the style altogether.

After publishing the file as a major version and approving it let’s apply the theme again. Theme comments are only processed at the time the theme is actually applied to the site. Therefore, any time you make a change to your file you will need to re-apply your theme to see the effect.

Theme applied and published

Here you can see that the ribbon row has now picked up the Dark 2 color of your theme, but the header is still the original green color. To change this you need to use the RecolorImage token in the header’s style declaration. The syntax for the RecolorImage token is as follows:

/* [RecolorImage(themeColor:”color”, method:”value”)] */

Once again color is the theme color you want to use with your image. Value can have one of three values, Tinting, Blending, or Filing. Tinting uses your theme color for the image colors, Blending mixes your theme color with the original color of the image and Filing completely fills the image shape with your selected color. In the image below you’ll note that I am going to recolor the image using the Accent 2 color and tint the image.

RecolorImage comment

Again you need to publish and approve the CSS file after making the change and then reapply the Vantage theme. The result is as follows:

Vantage applied tinting

If you choose to use the Blending option it would look like this:

Vantage applied Blending

One point I would like to make here, in my experience the value is case sensitive, Blending will work but blending will not.

So you can see that you have several options when it comes to themes and your custom CSS. Take some time and play around with the choices provided by using theme comments and see what effects you can come up with for your sites.

I hope this article helps you avoid some of the issues I ran into and gets you smoothly on the theme.

- Daniel Galant

 

 

Tuesday, October 9, 2012

SharePoint 2010 or 2013 Roles, Responsibilities & Support Policies from a SharePoint Consulting Perspective

Purpose
The purpose of this article is to share with the AIIM Community EPC Group’s consulting experience to standardize the nomenclature and define the responsibility of individuals who participate in SharePoint 2010/2013 projects, support and users of the overall SharePoint Enterprise Ecosystem. This is a great template or example to utilizes and keep in mind when thinking about your organization as a whole.

Myself and the team at EPC Group's goal is to develop a roadmap and “run-time” governance strategy for at least 36 months covering both SharePoint 2010 as well as SharePoint 2013 so that no gaps, major risks, or issues are left out of your organization’s SharePoint radar screen to ensure long-term success.

Introduction

Scope
This policy applies to all EPC Group Client SharePoint 2010/2013 initiatives, projects, support, usage and validation efforts.

Definitions
For a full list of definitions, (Your organization should implement a glossary or similar list of Definitions for your Enterprise SharePoint 2010 or SharePoint 2013 deployment), refer to the following site: (portal.yourcompany.com).

Roles
It is the responsibility of all individuals who participate in the creation of validation and project documentation to ensure the consistent use of the Roles and Responsibilities defined in this document.

Role
Description
Application Responsible Part of the System Owner group
Responsible for the day-to-day support and maintenance of the software application in accordance with the approved policies and procedures.
Ensure compliance of an IT system with regulatory requirements.
The Application Responsible closely interacts with the User Responsible
Can also be nominated for Project roles as a SME
Business Analyst A Business Analyst (BA) analyzes the organization and design of businesses processes and assess their integration with technology
Database Administrator (DBA) Part of the System Owner group
Individual responsible for a database system creation and maintenance in accordance with the approved procedures.
Can fulfill a project role as an SME
Design Lead
(Design Responsible, Design Authority)
Responsible for managing the design process in a given IS project
Approves the design documents and responsible for the implementation of the design
A project role
Developer
(Programmer)
Individual responsible for the coding of a program, or script
Individual responsible for a system’s configuration
A project role
Document Owner The person who takes the responsibility for creation, regular review and revision of a document.
End User In addition to using the system in accordance with approved procedures, end users may also be involved in the following activities through the life cycle:
  • Input to user requirements and specifications
  • Evaluation of prototypes
  • Testing
  • Acceptance of system and handover
  • Input to development of SOPs for use of system
  • Reporting defects
  • Identifying opportunities for improvement
Functional Head
(Department Head)
Management who is responsible for a company department or function
May act as Sponsor and may participate in requirements gathering and approves validation documents as applicable
Infrastructure Responsible Part of the System Owner group
Responsible for the day-to-day support and maintenance of infrastructure components in accordance with approved policies and procedures.
Can also be nominated for Project roles as a SME
IS Board Responsible for approving IS projects (depending on costs)
Assures the IS departments follow the general directions set by the CIO.
IS Management Person or persons controlling and directing the affairs of the IS department.
IS Quality Management Delegate (QMD. QMB) Individuals delegated by QA to perform designated QA functions. This may encompass day to day activities or specific to an IS validation.
Is an independent function within the IS organization
Ensures compliance with the applicable regulations, company standards and procedures defined in the IS QMS. Coaches and supports the Validation Lead as needed.
Defends IS Quality Management System standards in audits
The IS QMD closely interacts with QA.
Process Owner (Data Owner, Business owner, Business process owner) The process owner is ultimately responsible for ensuring that the computerized system and its operation is in compliance and fit for intended use in accordance with applicable SOPs. The process owner also may be the system owner.
Specific activities may include:
  • Approval of key documentation as defined by plans and SOP’s
  • Providing adequate resources (personnel including SME’s, and financial resources) to support development and operation of the system.
  • Ensuring adequate training for end users
  • Ensuring that SOPs required for operation of the system exist, are followed and are reviewed periodically
  • Ensuring changes are approved and managed
  • Reviewing assessment/audit reports, responding to findings, and taking appropriate actions to ensure compliance
  • Coordinating input from other groups (e.g. finance, information security, safety/HSE, legal)
Project Manager
(Project Leader)
Plans and controls a project encompassing functionality, schedule, costs and quality
Provides project updates to the project sponsor, steering committee and other management
Ensures intra-project team communications
Escalates issues and decisions to the appropriate staff and management
Delivers project documentation
QA
(QA compliance, QA oversight, Quality Unit, QA Reviewer, QSE)
Reviews and approves validation documents and SOPs to ensure regulatory compliance
Responsible for the coordination of regulatory audits
May be responsible for supplier audits
Reviews and approves SOPs and all other controlled documents
Manages the change control process and approve changes to related systems
QA closely interacts with the IS Quality Management Delegate
Requestor Individual making a request
Regulatory Affairs (RA) Department ensuring that the company complies with all of the regulations and laws pertaining to their business.
Service Desk Coordinator Coordinates incident resolutions and incident escalation
Sponsor
(Project sponsor)
Typically a member of a business area but IS management may also be a sponsor
Initiates projects
Signs off on project funding
Receives periodic project status updates
Steering Committee A group, typically composed of senior managers
Monitors project progress based on project reports provided by the Project Manager
Intervenes in project priority conflicts
Subject Matter Expert (SME) Qualified and experienced SMEs have a key role in performing reviews and assessments, and taking technical decisions, based on science based process and product understanding, and sound engineering principles. Different SMEs may be involved with different activities, e.g., during specification and verification.
SMEs can take the lead role in the verification of the computerized system. Responsibilities include planning and defining verification strategies, defining acceptance criteria, selection of appropriate test methods, execution of verification tests, and reviewing results.
SMEs may come from a wide range of backgrounds as required, including business process, engineering, IS, supplier, quality and validation.
Super User
(Power User)
Assists in the definition of user requirements.
Can provide user training
Can provide the first line support for support system users
Possess superior skill in an application and may be provided with additional administrative rights to support the system
System Owner The System Owner is responsible for the availability, and support and maintenance of a system and for the security of data residing on that system. The system owner is responsible for the availability, and support and maintenance, of a system and for the security of the data residing on that system. The system owner is responsible for ensuring that the computerized system is supported and maintained in accordance with applicable SOPs. The system owner also may be the process owner.
The System Owner acts on behalf of the users. A System Owner may:
  • Approval of key documentation as defined by plans and SOPs
  • Ensuring that Standard Operating Procedures (SOPs) required for maintenance of the system exist and are followed
  • Ensuring adequate training for maintenance and support staff
  • Ensuring changes are managed
  • Ensuring the availability of information for the system inventory and configuration management
  • Providing adequate resources (personnel including SMEs, and financial resources) to support the system
  • Reviewing audit reports, responding to findings, and taking appropriate actions to ensure compliance
  • Coordinating input from other groups (e.g., finance, information security, safety, legal)
Test Lead The person responsible for the design of the test activities. This may be a series of tests at different levels (e.g. Module testing, Integration testing etc.) and may include the use of code reviews and walk-throughs. The test lead can ensure:
  • The set of tests are structured to detect harmful failure modes of the system
  • confirm all individual tests / test cases adequately challenge the system for the likely failure modes and in case of intensive tests, instructions to the tester as to what objective evidence (screenshots, audit logs) are clear and adequate
Test Verifier
(Test Result Reviewer)
Individuals responsible for the verification of test cases ensuring the test case is filled out completely; all attachments are initialed, dated and labeled correctly and included with the executed test case. Test Verifier may:
  • confirm the testing is complete (i.e. No tests are un-executed)
  • confirm the tester(s) can be identified via their signature / initials and a legend
  • confirm that the test cases/script/specifications were approved by the authorized parties before execution
  • confirm that all defects uncovered during testing have triggered the appropriate defect management system
  • Write and sign test summary report
Tester Responsible for the complete execution of a test case, collection of required evidence (e.g. screen prints)
User Responsible Designated individual appointed by the Process Owner who is responsible for end user tasks on a system
May coordinated the activities of other End Users
The User Responsible closely interacts with the Application Responsible and/or the (Super) User(s)
Validation Responsible In concert with the Business Owner and System Owner, assumes responsibility for the technical aspects of the Computerized System Validation and the Validation Documentation
May participate in defending the validation status of the Computerized System to external auditor
As a team lead or as an individual contributor will ensure proper planning, execution and documentation of an IS validation effort on a Project
May Approve the (Project) Validation Plan and Validation Report
Contributes to the development of Validation documentation for an IS system.
People Organization

EPC Group Client's It Operations
IT Operations oversees the teams of Quality Assurance, System Administration and Multi-Tiered Support
  • Standard On-call support is provided from 7am to 5pm CST.
  • Premium On-call outside of these times is available at an additional cost to the customer.
Farm Administrator
The Farm Administrator manages the operation of production, pilot, test, and development environments for SharePoint. They control the application at the Operating System (OS) and above and help execute approved change requests. The Farm Administrators have full central administration rights, full SharePoint services rights and provision security for the site collections. They assign permissions to the Site Collection Managers.

The Farm Administrator is an essential member of the SharePoint Team and frequently collaborates with other Farm Administrators and Site Collection Managers to resolve problems, assist with issues, or knowledge transfer. The Farm Administrator has the same access to all other hub farm instances and is an OS administrator for the local farm.

System Administrator
The System Administrator is a part of the Infrastructure group. The System Administrator manages the operation of production, pilot, test, and development environments for SharePoint. They control the application above the hardware to the Operating System (OS) level and help execute approved change requests. The System Administrator does not have central administration or SharePoint services rights and has no special administrative access within SharePoint.

The System Administrator is not a member of the SharePoint Team but works with the Farm Administrator on requests. The System Administrator is an administrator at the OS level for the local farm.

The System Administrator follows the procedures for maintenance, backup, recovery, and overall change management.

The System Administrator provides monitoring of the system through:
  • Usage analysis and tuning.
  • Automatic monitoring and event notifications.
The System Administrator provides maintenance of the servers (service packs, hot fixes, etc).
The System Administrator provides support for hardware and software of the SharePoint location.
The System Administrator provides documentation on the installation and configuration of the system in its environment. The system must be documented well enough so that it can be reinstalled and reconfigured to last known good operating standards, should it become necessary to do so.

Site Collection Managers
Manages the site collection on the production environment for SharePoint. Site Collection Managers are those within the SharePoint Team with the specific goal of promoting new collaboration tools and other SharePoint applications within their location for the sites they manage to help improve efficiency and increase productivity.

They do not have access to the operating system, central administration or SharePoint services. The Site Collection Manager is an integral member of the SharePoint Team and frequently collaborates with other Site Collection Managers and Farm Administrators to resolve problems, assist with issues, or knowledge transfer.
  • The Site Collection Manager advocates and promotes SharePoint through leadership by example.
  • The Site Collection Manager is the liaison between the SharePoint Team leadership and the business.
  • In addition, they should be able to support the business in implementing any changes in methodology that SharePoint 2010 \ 2013 will bring.
The Site Collection Manager should also be:
  • Comfortable in working with new applications.
  • Able to quickly learn the capabilities of SharePoint tools.
  • Able to demonstrate strong functional knowledge of the tools to others.
The Site Collection Manager will be expected to network frequently in order to ensure they are well informed on the perception and progress of the sites. Such networking would involve interaction with the SharePoint Team, local users, and local management. Interaction with the Central Collaboration Teams would be via the SharePoint Team Meetings, local training sessions, and other communication venues such as brown bag lunch sessions.

Site Collection Manager must have the support and approval of local management.
Additional tasks could be delegated such as the following:
  • Creating sub-sites within existing sites.
  • Managing security of the SharePoint site.
  • Creating new workflows and managing site content.
Database Administrators (Sometimes the same role as other High Level roles already listed depending on the size of your organization)

The Database Administrator is a part of the hub Infrastructure group.Database Administrators are responsible for installation, configuration, backup, recovery and monitoring of the SQL Server databases required by SharePoint.They do not have central administration or SharePoint service rights and have no special administrative access within SharePoint.The Database Administrator is not a member of the SharePoint Team but works with the Farm Administrator on requests.

Quality Assurance (Again, this role may be combined with another role already listed depending on your available resources or skillsets)

A quality assurance function will create and execute test plans to certify all software changes. This team will be comprised of the Infrastructure Hosting Team and the Business Owner Developer team for the Site Collection.

System Administration
Manage the operation of Production and Staging. Controls the hardware and executes approved change requests. This team is comprised of the Infrastructure Hosting Team

Site Collection Administrators
Site Collection Administrators are persons with the specific goal of promoting the new Collaboration tools within their location, to help improve efficiency and increase productivity. This teal will be comprised of the Business Owners designated staff.

Multi-Leveled Support
The multi-leveled support organization is structured in 3 levels as follows:

Level 1 Support

The Service Desk is Tier 1 and it provides business operations basic service availability support between 6:00 A.M. – 12:00 A.M EST Monday thru Friday and 7:00 AM – 7:00 P.M. CST on the Weekends
The Help Desk is Level 1 and it provides basic service availability support via the ticket queue at each location.
The Help Desk at each hub location is Level 1 and is governed by the following policies:
  • Addresses user issues by monitoring the Help Desk queue.
  • The Help Desk has the knowledge of the network, the desktop, the corporate servers and the personal accounts status.
  • The Help Desk can resolve basic computer-user issues.
  • No specific SharePoint expertise exists here, and SharePoint issues that cannot be resolved by the Help Desk will be passed to the next support level based on a decision tree outlined by the local Help Desk.
Level 2 Support
-Tier 2 Support is the SharePoint-specialist support team and Site Collection Administrator should be a Subject Matter Expert (SME).
 
-Level 2 Support is the SharePoint specialist support team which provides more advanced support at each location. Site Collection Managers are considered to be in Level 2 support.
 
-Level 2 Support team is the software development team that creates applications, Web Parts, and other customizations made through the EPC Group Client “Request for Change” (or similar) Process.
 
-Level 2 Support is also the SharePoint specialist support team and is governed by the following policies:
  • Level 2 resolution policies are based on the expert knowledge of SharePoint.
  • Level 2 Support has privileged access to the development, test, and pilot SharePoint environments.
  • Level 2 has specific access privileges to the production SharePoint environment.
  • Level 2 privileges allow for processing site creation requests and creating new sites.
  • Level 2 resolutions recommend specific scenarios that users themselves can perform.
  • Level 2 staff may also work with the Site Collection Manager to investigate sites for the duration of a support case.
  • Level 2 analyzes user requests and makes recommendations on issues and resolutions in the environments.
Level 3 Support
Tier 3 Support team is the software development team that creates Applications, parts and other customization per requestor’s specifications. The "Hosting Team” (Facilities (Hardware and OS), Application).
 
Note: When I refer to the “Hosting Team” here is typically refers to the internally “on-premises” hosted Private Cloud as EPC Group specializes in mid-size to Fortune 500 size implementations.
 
Level 3 Support the infrastructure and deployment of solutions and features to production farms.
 
Level 3 Support are the Farm Administrators and System Administrators which maintain the SharePoint farms as well as deploys packaged solutions to production servers and is governed by the following policies:
  • Level 3 resolution policies center on the deployment of solutions to Production servers.
  • Level 3 issue resolutions are complete when the completed product(s) are deployed and tested in the SharePoint Production Environments.
  • Level 3 applies application patches and hotfixes to the hub locations’ SharePoint environments.
Business Operations
The SharePoint Steering committee oversees the engagement of the businesses and the SharePoint Team in the promotion and adoption of best practices around SharePoint.

Global Champions (Power Users, Super Users, etc.) (Extreemly KEY!)
Global champion drives the process of aligning evolution of the SharePoint project with the evolving business needs and Company direction.
Global Champions will be comprised from a combination IT PM and Business Operations

"Key Stakeholders" and Business OWNERS
"Key Stakeholders" \ Business Owners manage the overall design and functionality integrity of SharePoint from a business perspective. The ITPM and Business Owners do not have to be IT experts, but the job function typically includes responsibility for internal communications, intranet portals, external communications, and external portals.

SharePoint Governance Council
The SharePoint Steering committee will be comprised of executive sponsor not from IT. The committee will meet regularly with defined success criteria and measurable goals based on implementation phase specifics.

The SharePoint Steering Committee will meet regularly to revisit structure, responsibilities and membership to ensure maximum effectiveness as well as potential scope changes for the portal due to changes in business conditions and technology.

The role of the SharePoint Steering Committee will be:
  • Aligning portal initiatives to overall corporate business goals.
  • Provide administrative and functional guidance to the portal management team.
  • Approve project scope and monitor and continually assess the portal project viability.
  • Resolve corporate conflict/issues.
  • Determine corporate standards.
  • Provide approval to proceed through each phase of the project.
  • Defining all governance, standards and policies.
  • Creating content publishing policies and assigning departmental ownership.
  • Driving portal branding/look and feel (some companies may assign partial or full ownership to marketing).
  • Navigational design/taxonomy.
SharePoint Team (Again this can be combined with other roles based on your organization, its size, your available skillsets and also other major IT initiatives going on within your organization)
The SharePoint Team drives the process of aligning each location’s SharePoint environment with evolving business needs and company direction. The SharePoint Team consists of the SharePoint Team Manager, SharePoint System Architect, SharePoint Application Architect, SharePoint Farm Administrators, and Site Collection Managers.

SharePoint Steering Committee (Extremely KEY!)

Note:My team and I at EPC Group wrote another article for the AIIM Community about 6 months ago regarding our Consulting Best Practices Approach to Building a SharePoint Steering Committee which can be found here:

http://www.aiim.org/community/blogs/expert/SharePoint-Consulting-Developing-a-SharePoint-2010-Steering-Committee

The SharePoint Steering Committee will be comprised of Senior Management and SharePoint Stakeholders. SharePoint Stakeholders are defined as those in the business units which rely on the SharePoint portal as a part of their business operation.

The committee will meet regularly with defined success criteria and measurable goals based on project definition, design and timeline.
The Steering Committee is chaired by the SharePoint Team Manager. Membership includes CIO, Applications Manager, Director of Corporate Communications or their equivalent. Membership may also include key line of Business Directors and Managers.

The SharePoint Steering Committee will meet regularly to revisit structure, responsibilities and membership to ensure maximum effectiveness as well as potential scope changes for the corporate and local portals due to changes in business conditions and technology.

The role of the SharePoint Steering Committee will be:
  • Aligning portal initiatives to overall corporate business goals.
  • Provide administrative and functional guidance to the SharePoint Team.
  • Approve project scope, monitor, and continually assess portal project viability.
  • Resolve business conflict/issues.
  • Determine corporate standards.
  • Approve all governance, standards and policies.
  • Approve content publishing policies and assigning departmental and functional ownership.
  • Approve portal branding/usability/look and feel.
  • Approve changes to the SharePoint Governance Document.
Power Users
Power Users serve as the centralized, primary role for ensuring that content for a particular site is properly collected, reviewed, published, and maintained over time. The Power Users must have good working knowledge of SharePoint, but the primary expertise is business-focused.

SharePoint Roles

Operations Roles
Permissions and responsibilities in the operations roles are persistent throughout all farms.
Roles and responsibilities defined below are specific to SharePoint Products and Technologies and third-party tools used for operations and maintenance of SharePoint Products Technologies.

RoleResponsibilities and TasksGroupPermissionsTrustee
SharePoint Team Manager
  • Responsible for all SharePoint Product and Technology Efforts.
  • Leads SharePoint Steering Committee.
  • Leads SharePoint Team.
  • Major SharePoint Technology Decision Maker.
SharePoint Team
  • Full Control – full control given at the web application policy level for every web application in all farm locations.
  • Admin Control – full control to all central administration and SharePoint services in all farm locations.
  • May or may not have system administrative or SQL administration rights.
Application Manager/Infrastructure Architect
SharePoint
Application Architect
  • SharePoint Development Team Lead
  • Third Party Configuration
  • Line of Business Integration
  • Governance Model/Best Practices Enforcement
SharePoint Team
  • Full Control– full control given at the web application policy level for every web application in all farm locations.
  • Admin Control – full control to all central administration and SharePoint services in all farm locations.
  • Has system administrative or SQL administration rights in non-production systems.
SharePoint Team Manager
SharePoint
System Architect
  • AD and Exchange Integration
  • Profile Synchronization
  • Patch Management (Validation
  • and Testing)- Responsible for SharePoint farm infrastructure design, installation, guidelines and best practices.
  • Governance Model/Best Practices Enforcement
  • System Administrators day to day support
  • Search Administration
  • Farm Administrators day to day support
  • Third Party Configuration
SharePoint Team
  • Full Control– full control given at the web application policy level for every web application in all farm locations.
  • Admin Control – full control to all central administration and SharePoint services in all farm locations.
  • Has system administrative or SQL administration rights in production systems.
SharePoint Team Manager
Active Directory Manager
  • Active Directory Management
  • DNS Management
  • Exchange Management
Infrastructure Team
  • Will not have access to portal or site configuration settings and will not be able to make any changes to the application.
SharePoint System Architect
Network Engineer
  • Firewalls
  • WAN
  • WAN Optimization
  • Remote Access Management
  • External Access Management
  • Load Balancing
Infrastructure Team
  • Will not have access to portal or site configuration settings and will not be able to make any changes to the application.
SharePoint System Architect
SharePoint Solution Manager
  • Responsible for SharePoint services, policies, procedures, and governance/best practice enforcement.
  • Liaison between business users and SharePoint Team.
  • Day to day support for Site Collection Managers.
  • Serves as SharePoint champion for all locations.
SharePoint Team
  • Will not have system administrative or SQL administration rights.
  • Local Full Control– full control given at the site collection level
SharePoint Application Architect
SharePoint System Architect
SharePoint System Administrator
  • Responsible for SharePoint farm infrastructure change requests.
  • Responsible for day to day maintenance of SharePoint farm OS operations and uptime.
Infrastructure Team
  • Will not have access to portal or site configuration settings and will not be able to make any changes to the application.
IT Manager
SharePoint
SQL Database Administrator
  • SQL Server database backup and recovery, SQL configuration, SQL upgrades and monitoring.
  • Responsible for databases, site collection, and site backups.
Infrastructure Team
  • Will not have access to portal or site configuration settings and will not be able to make any changes to the application.
  • SQL Administrative rights
IT Manager
SharePoint Solution Analyst
  • Tests custom code and third party tools in non-production systems
  • Defined requirements for proposed solutions to determine whether the solution is Commercial Off the Shelf (COTS), requires custom development or requires feature extension
SharePoint Team
  • Full Control– full control given at the web application policy level for every web application in virtual lab environments
  • Admin Control – full control to all central administration and SharePoint services in virtual lab environments
  • Has system administrative or SQL administration rights in virtual lab environments
SharePoint Application Architect
SharePoint System Architect

Local Group Roles

End-User Roles

  • These roles will be managed by the Farm Administrator.
  • Users may belong to more than one group to add additional permissions.
  • Users may also be removed from lower level roles as higher level roles permissions may encompass the permissions of the lower level role.

Roles Responsibilities and Tasks Training Permissions Trustees
Site Collection Manager (IT)
  • Manage Features and Solutions for site collection.
  • SharePoint site provisioning for site collection
Instructor led with good understanding of site administration, security, content creation, feature deployment Access defined at the SharePoint application level. No access at the system level. Farm Administrator
Site Collection Owner (Solution Manager in Development, IT in Production)
  • Site Collection Owner
    Content creation
    Manage content.
  • Sub-site management
Instructor led with good understanding of site administration, security, content creation Access defined at the SharePoint application level. No access at the system level. Site Collection Manager
Farm Administrator
Site Owner(Solution Manager, IT and End User)
  • Site Owner
    Content creation
    Manage content.
Instructor led with good understanding of site administration, security, content creation Access defined at the SharePoint application level. No access at the system level. Site Collection Manager
Farm Administrator
Developer (IT Dev is the SharePoint Team). This group exists on all sites at time of creation but is removed prior to go-live.
  • Manage the site layout and structure.
  • Create custom workflows.
  • Create custom Web Parts, solutions and features.
  • Responsible for building the framework and features of the portal.
  • Modify SharePoint templates as needed.
  • Write ASP.Net code.
  • Participate in design tasks as needed.
  • Participate in development and testing as needed.
    Create custom forms.
Instructor led training with CBTs. MS training for Visual Studio, ASP.Net and SharePoint Designer Developers Full control of non-production systems.
Access defined at the SharePoint application level. No access at the system level.
Access does not exist in the production environment.
SharePoint Application Architect
Member
  • Content creation (documents, lists).
    Contribute to collaboration sites (blog, wiki).
    Initiate workflows.
CBT with good understanding of document libraries and lists Access defined at the SharePoint application level. No access at the system level. Site Owner
Approver
  • Approve content (documents, lists).
  • Initiate workflows.
CBT with good understanding of content approval and workflows Access defined at the SharePoint application level. No access at the system level. Site Owner
Reader
  • View content
N/A N/A Site Owner

End User Permissions
End user Permissions based on the user roles for the Production environments are listed below.

List Permissions (This is an example for SharePoint 2010 and SharePoint 2013 to keep in mind!)
Permissions
Site Collection
Manager
Owner
Developer
Member
Approver
Reader
Manage Lists - Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
Y
Y
Y
N
N
N
Override Check Out - Discard or check in a document which is checked out to another user.
Y
Y
N
N
N
N
Add Items - Add items to lists, add documents to document libraries, and add Web discussion comments.
Y
Y
Y
Y
N
N
Edit Items - Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries.
Y
Y
Y
Y
Y
N
Delete Items - Delete items from a list, documents from a document library, and Web discussion comments in documents.
Y
Y
Y
Y
N
N
View Items - View items in lists, documents in document libraries, and view Web discussion comments.
Y
Y
Y
Y
Y
Y
Approve Items - Approve a minor version of a list item or document.
Y
Y
Y
Y
Y
N
Open Items - View the source of documents with server-side file handlers.
Y
Y
Y
Y
Y
N
View Versions - View past versions of a list item or document.
Y
Y
Y
Y
Y
N
Delete Versions - Delete past versions of a list item or document.
Y
Y
Y
N
N
N
Create Alerts - Create e-mail alerts.
Y
Y
Y
Y
Y
N
View Application Pages - View forms, views, and application pages. Enumerate lists.
Y
Y
Y
Y
Y
Y
Site Permissions
Manage Permissions - Create and change permission levels on the Web site and assign permissions to users and groups.
Y
N
N
N
N
N
View Usage Data - View reports on Web site usage.
Y
Y
Y
N
N
N
Create Sub-sites - Create Sub-sites such as team sites, Meeting Workspace sites, and Document Workspace sites.
Y
Y
Y
N
N
N
Manage Web Site - Grants the ability to perform all administration tasks for the Web site as well as manage content.
Y
N
N
N
N
N
Add and Customize Pages - Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services-compatible editor.
Y
Y
Y
N
N
N
Apply Themes and Borders - Apply a theme or borders to the entire Web site.
Y
Y
Y
N
N
N
Apply Style Sheets - Apply a style sheet (.CSS file) to the Web site.
Y
Y
Y
N
N
N
Create Groups - Create a group of users that can be used anywhere within the site collection.
Y
N
N
N
N
N
Browse Directories - Enumerate files and folders in a Web site using SharePoint Designer and Web DAV interfaces.
Y
Y
Y
Y
Y
Y
View Pages - View pages in a Web site.
Y
Y
Y
Y
Y
Y
Enumerate Permissions - Enumerate permissions on the Web site, list, folder, document, or list item.
Y
Y
Y
Y
Y
N
Browse User Information - View information about users of the Web site.
Y
Y
Y
Y
Y
N
Manage Alerts - Manage alerts for all users of the Web site.
Y
Y
N
N
N
N
Use Remote Interfaces - Use SOAP, Web DAV, or SharePoint Designer interfaces to access the Web site.
Y
Y
Y
Y
Y
Y
Use Client Integration Features - Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.
Y
Y
Y
Y
Y
N
Open - Allows users to open a Web site, list, or folder in order to access items inside that container.
Y
Y
Y
Y
Y
Y
Edit Personal User Information - Allows a user to change his or her own user information, such as adding a picture.
N
N
N
N
N
N
Personal Permissions
Manage Personal Views - Create, change, and delete personal views of lists.
N
N
N
N
N
N
Add/Remove Personal Web Parts - Add or remove personal Web Parts on a Web Part Page.
N
N
N
N
N
N
Update Personal Web Parts - Update Web Parts to display personalized information.
N
N
N
N
N
N
Software

Standard Installation
The standard installation will be based on the software requirements outlined in the SharePoint and Project Server Best Practices Document.

Web/Application Server
The server hosting the SharePoint and Project Server web application components must reside on a dedicated server separate from the database server.

Database Server
All SharePoint environments will require a dedicated SQL database server(s) that’s (are) separate from the web application server.

ADD-On Software
Additional software may be procured or developed and added to the standard installation following software development and deployment policies. This includes:
  • Web Parts, applications, list and library templates, site templates and other features and solutions, including out-of-the-box offerings which have been made available to the enterprise.
  • Web Parts at farm level, site collection level or at site level.
Software, feature and solutions requests must go through the SharePoint Support Request. All solutions, software, third party integration tools acquired or developed will be required to be added to all web front-end and applications servers following approval from the SharePoint Team.

Policies
All persons are subject to the policies within this document and are also subject to the provisions of applicable EPC Group Client Policies, including provisions for discipline for violation of this policy.

People

Quality Assurance
  • Quality Assurance team constructs test plans and conducts tests for all candidate Applications and Web parts.
  • QA Manager certifies candidate component as PASS or FAIL.
  • Maintains regression test plans.
System Administration
  • The System Administration team has full access to the administration of the Project Server Farm.
  • System Admin team follows the procedures at the hosting Data Center for maintenance, backup and recovery and overall change management.
  • Auditing of security logs
  • Monitoring: Usage analysis and Tuning; automatic monitoring and event notifications.
  • Maintenance of the servers (service packs, etc.)
  • Set and manage quotas for sites
  • Provide self-support for hardware and software.
  • Document the installation and configuration of the system in its environment. The system must be documented well enough so as to be reinstalled and reconfigured to last known good operating standards, should it become necessary to do so.
  • Document and maintain a document of Scheduled Tasks.
  • Document the installation and configuration of the system in its environment. The system must be documented well enough so as to be reinstalled and reconfigured to last known good operating standards, should it become necessary to do so.
Application Administration
  • Has full access to the administration of the SharePoint Farm.
  • Auditing of security logs
  • Set and manage quotas for sites
Multi-Tiered Support
The SharePoint National Help Desk, Tier 2 Support, plays the leading role in addressing user issues by monitoring the National Help Desk queue as well as the EPC Group Client SharePoint Bulletin Board.

The forum of the SharePoint bulletin board is a free exchange of ideas and experiences.

The Tier 2 Support staff, as well as the SharePoint Champions will monitor the bulletin boards to ensure that no disinformation gets propagated on the bulletin board.

Multi-tiered support organization is structured in 3 levels as follows:

Tier 1 Scope and Resolution
The Help Desk is Tier 1 and it provides 24/7 basic service availability support and is governed by the following policies:
  • This desk has the knowledge of the network, the desktop, the corporate servers and the personal accounts status.
  • It can also triage all computer-user issues. No specific SharePoint expertise exists here, and SharePoint issue resolution is based on a decision tree provided by Tier 2.
Tier 2 Scope and Resolution
Tier 2 Support is the SharePoint-specialist support team and is governed by the following policies:
  • Tier 2 resolution policies are based on the expert knowledge of SharePoint paired with a limited set of privileged access.
  • Tier 2 privileges allows for processing site creation requests and creating new sites.
  • Tier 2 resolutions recommend specific scenarios that users themselves can perform.
  • Tier 2 staff may ask a site collection owner to grant him/her a temporary owner’s role on the investigated sites for the duration of a case investigation.
  • Tier 2 resolutions normally do not require deployment of new software code or underlying infrastructure. If new software components are required, then the process of deploying new software is followed.
  • Tier 2 analyzes user requests and makes recommendations on new Web parts and Applications
  • Cases that require an extensive development or a procurement of software are then escalated to Tier 3.
  • Tier 2 Support has privileged access to the Staging/Test equipment.
  • Tier 2 has specific access privileges to Production.
Tier 3 Scope and Resolution
Tier 3 Support team is the software development team that creates Applications, parts and other customization per requestor’s specifications and is governed by the following policies:
  • Tier 3 resolution policies center on the development of solutions through new software or custom components.
  • Development objectives are selected from the collection of issues escalated to Tier 3 from Tier 2.
  • The selection criteria, priority and schedules are set by the management team (IT and Product Champion).
  • Tier 3 issue resolutions are complete when the completed product(s) pass Customer Acceptance Test before deployment to Production.
  • Tier 3 resolutions are packaged, detailed and integration tested and given to the Systems Support team to deploy to production servers during pre-defined maintenance window
Site Collection Administrators

Site Collection Administrators advocate and promote SharePoint through leadership and example.
Experiences shared on the EPC Group Client Bulletin Boards, as well as through local venues will help others follow. Site Collection Administrators may post “How to” answers directly to other users or to the Bulletin Boards.

The Site Collection Administrator should have good knowledge of the business processes in their location or domain, and should be able to present the value that the new tools will bring to both the business process owners and the end users. In addition, they should be able to support the business in implementing any changes in methodology that the new applications will bring.

The Site Collection Administrator should also be:
  • comfortable in working with new applications
  • able to quickly learn the capabilities of SharePoint tools
  • able to demonstrate strong functional knowledge of the tools to others.
The Site Collection Administrators should be well respected within their location, and able to lead the change within their location with a positive attitude at all times.

The Site Collection Administrators will be expected to network frequently in order to ensure they are well informed on the perception and progress of the project, with a good understanding of the real issues. Such networking would involve interaction with the central Project Team, local users and local management.

Interaction with the central Project Team would be via Site Collection Administrators Meetings. Local interaction could take the form of weekly or 2-weekly Lunch and Learns, site presentations and local meetings with management.

Site Collection Administrators must have the support and approval of local management. An agreement must be in place to allow them to dedicate an agreed amount of their working time to the role.
  • Additional Tasks that could be delegated:
  • Creating sub-sites within existing sites
  • Managing the user base of the SharePoint site
  • Customizing the navigation (that is, the Quick Launch and Top Link bars) of a site
  • Creating new workflows & managing site content types
Summary
I hope this will assist you in thinking of the big picture of a SharePoint 2010 or SharePoint 2013 implementations roles and responsibilities. If you think though each element of this you’re going to also be integrating with Active Directory, External Data Sources, Existing .NET or business critical applications that may exist, as well as your organization's reporting tools.

You may find (more than likely you will) that Microsoft PerformancePoint (2010/2013) and its integration with SharePoint will allow for seamless reporting both for data residing inside as well as outside of SharePoint. If you then mix in the seamless integration with Team Foundation Server (TFS) for code management (testing, etc.) and the Enterprise Content Management \ Records Management (ECM\ ERM) with industry leading workflow and mobile compatibility this document (article) will soon start to bleed over to your organization's Governance documents, run-time support and records management policies.

I will continue to build on this in my next article, the 3rd part of "Dissecting a Decade of SharePoint Consulting Success, which I am trying to paint the picture of all sides of a SharePoint implementation from a SharePoint Consulting perspective or that real-world side when multiple curve balls are thrown in and a solution must still be achieved.

Examining a Wiki-Based Infrastructure in SharePoint 2010

By Timothy Calunod - EPC Group Sr. SharePoint Consultant

Our goal is to create a publishing Wiki system relying on the Wiki-based features and possibly leveraging other related technologies. In this post, we will examine how we can deploy Sites and Site Collections to support our Wiki-based publishing infrastructure.

Infrastructure Overview


It is not the logical infrastructure – the Web Applications, Site Collections and Sites – that complicates the solution, as the creation and configuration of these objects are not where the challenges lie, but rather the features and limitations of the Wiki Sites, Libraries and Pages to meet the need of the goal. Therefore, discussion of those particulars will be limited.

Our infrastructure will be simple to begin: one Web Application hosting at least two Site Collections, one Site Collection for the specific department and related manual, and one Site Collection for general information, navigation, and other resources. We will begin our focus on the departmental Site Collection and the individual manual site. Within the manual site, a default Table of Contents page will be created and each chapter will be isolated to a Wiki Library.

Creating the Structure


1) Create the Wiki Web Application

Nothing of particular challenge in this stage; we choose the host header name and set DNS entries, then create at least one Content Database for either the entirety of the Wiki content or different databases for each Site Collection. This would provide support for restoring the Wiki-based content separate from other content, as well as support individual manuals by department if each divisional Site Collection has been placed in its own database. It would also be a good idea to generate a wildcard inclusion managed path to separate the naming for the content as well.

2) Create the Wiki Site Collections

We create at least two Site Collections, one at the root and additional ones under our wildcard inclusion managed path, such as /dept in case additional needs may arise that will create other manuals for different reasons. The root Site Collection will act as the main navigation point and hold collected resources and tools for everyone generating content within the Wiki Site Collections. This will not contain any of the Wiki-based manuals.

The additional Site Collections will represent different departments generating the content, although they could easily be divided up into purposes, locations or any organizational division appropriate to the business. The key decision will be who should control access for publishing and reading the content, and represent that control appropriately. The Top-Level site of the specific Site Collection will provide navigation, resources and other tools for all related manuals in this particular Site Collection.

Regardless of organizational divisions, every Site Collection Top-Level Site will use the Enterprise Wiki Site Template.


3) Create the Wiki Subsites

Since we will be building an Employee Manual, we will place this site within an HR Site Collection as a subsite as this manual is typically generated by HR. By separating the entire manual into its own site, we can control individual chapters by Wiki Libraries and each section will be a Wiki Page within the appropriate chapter Wiki Library. This will provide a quick and simple navigation control for our sections within the chapter, and also for each chapter for the manual.

When the subsite for our manual is created from the Enterprise Wiki Site Template, a default library called Pages will be created. This Library, although associated with the default Wiki Pages normally generated when a Wiki Library is created, is actually a publishing page library with the Enterprise Wiki Page Publishing Page attached to it as well as a Project Page and Redirect Page. This default library will be used to hold the Table of Contents page for the entire manual, plus additional pages such as a How-To-Use guide and other tools and information.

Because we created separate Site Collections to divide management for the manuals, as we create new manuals we can create additional subsites to represent each manual. This also allows manual-specific control over the content through Site-Based security, and if the security requires such, a manual-based Site that is shared by more than one department can be made in a different Site Collection to represent this control.

Additional resource libraries, such as storage for forms, printable documents, collaboration resources and tools, will be generated either at the subsite level or at the Top-Level site, depending on how globally available these resources need to be.


4) Create the Wiki Libraries

For each chapter, we create a Wiki Library. This will automatically generate the Home.aspx and "How To Use This Wiki".aspx pages. The Home.aspx page automatically created will become the Chapter Table of Contents, and each section will be created as a Wiki Page as needed. We should keep the How To page for additional reference and instruction on collaborating through Wikis, although this information may also be consolidated into a User Guide for the manual.

There is no need to create additional Wiki Libraries in subsites beyond the required chapter, but the Top-Level Site in the Site Collection may have additional Wiki Libraries, including ones related to using and navigating content.

Naming Conventions for each Library should represent the organization naming, but the Title properties can reflect the individual chapter titles as well. This will provide a fast and easy way to generate navigation in the Quick Launch bar based on the chapters, but the generation of the Table of Contents will be handled differently.


5) Create the Wiki Pages

Since each Wiki Library will be a chapter, each Wiki Page in the Wiki Library will represent sections. This structure will also support multi-tiered structures that have many subsections per section but keep all related section information on the same page. Navigation within a section page presents additional configuration requirements.

Naming Conventions should also be applied as they are for the chapter libraries. Page names will be simpler and use text/HTML in the document itself to represent the complex naming, such as the section and subsection divisions and names. Unlike the chapter Libraries however, the order of pages will be controlled by views in some cases for navigation.


Analysis


We find that our logical infrastructure is quite simple and no additional configurations per Site Collection, Site, Library or Page has been discussed. However, the need to configure our infrastructure further is certainly evident, as such things as navigation, version control, content approval and other web content management features.

Also, the focus thus far has been on the Employee Manual subsite and its content, but attention to the divisional/departmental Top-Level Site and the root Site Collection must also be given to create a more usable structure since this will not be an additional Site Collection attached to the standard collaboration Web Application.

Object in the Architecture Purpose for Division
Site Collection by Department/Division Separates Ownership of Content by natural boundaries
Creates Shareable Ownership of Content
Supports individual backup/restore for Content
Top-Level Site of Site Collection Department/Division Creates central navigation for all manuals in Site Collection
Provides centralized tools for all manual subsites
Contains additional, non-Wiki content (forms, tracking, discussions)
Controls shared resources (templates, web parts)
Pages Library in Manual Subsite Controls Table of Contents for All Manuals
Subsite in Department/Division Site Collection Represents each different manual for separated management
Organizes sections of manual into simpler groups
Creates simple navigation management for content
Library in Manual Subsite Separates Manual Chapters
Creates automatic navigation
Separates Management of individual Chapters
Pages Library in Manual Subsite Controls Table of Contents for Manual Chapters
Provides additional content related to manual (how-to's)
Pages in Chapter Libraries Separates Chapter Sections
Supports Subsections in each Section

Additional Configurations


Within the manual subsite there will be additional configurations that will be set to take advantage of the collaboration features along with the Wiki features for SharePoint. Wiki Libraries normally use Simple Versioning since the changes to the Wiki pages would all be major ones. However, for drafting and approval control, the Wiki Libraries will have additional settings, including:

  • Enforced Check-Out for editing control
  • Comprehensive Versioning for drafting
  • Draft Item Security set for Approve to limit change visibility
  • Content Approval to control publishing
  • Custom metadata to indicate Chapter and Section
  • Custom Views to sort and show content based on Chapters, Sections, or other metadata

Wiki Libraries also suffer from some specific limitations to make using the collaboration features a bit simpler, such as not using folders, not allowing list templates and not allowing the attaching of or displaying content types. With SharePoint 2010, such limitations also include limiting custom columns from being displayed on the web page. However, the custom columns can be used in other ways, as we will discuss later.

Also, changes made to the navigation displays such as through the Quick Launch or Wiki Pages will also need to be configured.

Observation

Understandably, there is a higher level of complexity that simply creating an Enterprise Wiki site with numerous Wiki Libraries. Most of these additional configurations do not have to be applied although they will support a publishing system for the Wiki Pages. For the Employee Handbook manual subsite, the logical architecture along with the collaboration settings and Wiki-based features would be enough. But to continue to make the infrastructure useful, additional roles related to the Site Collections and Top-Level Sites also need to be defined.