A checklist for consideration when creating a SharePoint Platform

A checklist for consideration when creating a SharePoint Platform

I have often been asked; “Hey Geoff, what points do I need to take into consideration whilst creating a SharePoint platform service”?

Configuration Management is the answer – “the combination of technical documentation, product pack information, user rules, continuity planning; – which helps create platform policies, platform change management rules and helps sustain the platform in its lifecycle”.

In ‘creating’ a SharePoint platform service, and I am purposefully ignoring high level ‘so called’ business points, no-one in the right mind would stick a SharePoint install DVD, or mount a SharePoint install image, click Next, Next and Next again, enter some configuration details without recording anything (using the ‘It’s Easy so why do I need to write anything down’ excuse), and then announce to the client “Eureka! I have given you a SharePoint platform – I declare that it has been successfully implemented!” (and real-world I have actually witnessed this).

SharePoint configuration management is the answer. Why? Because decisions concerning the implementation need to be recorded, as it is likely that the implementation configuration of SharePoint will change, or referred to, or added to in its lifecycle. So that means, you need to have a reference to each of these points in at the very least your Detail Level Plan for your SharePoint platform. Those should be then referred to in associated user policy documents as necessary.

 So, here’s my take: (Note – most of these are technical checklist items, for the business side, see the user requirements checklist. Additionally, this refers to SharePoint 2007, 2010 and 2013 so examine each point as necessary and apply it to your version of SharePoint).

Governance and Culture Planning Points

  • Can users access information via Web folder clients?
  • Can users create and manage their own Web sites?
  • Is the administration of mission critical data distributed?
  • How are records and documents described using metadata and is that consistent across departments, divisions and agencies?
  • Have you trained end-users on how to administrate sites before they need to manage them?
  • Have you decided on who will assign users and permissions in SharePoint?
  • Have you decided on who will create and approve content for portals?
  • Have you decide on who will be able to create new sites?
  • Have you decided on who will be able to publish content to web sites?
  • Have you decided on who will be able to customise sites?

Naming Conventions

  • Database Names?
  • URLs (host headers)?
  • Stand-alone site collection URLs?
  • Managed path names and if so what are they?
  • Document Library names?
  • Active Directory SharePoint accounts?
  • Content source names?
  • Scope names?
  • Server names?
  • Web application names?
  • Web application folder names?
  • E-mail enabled list names and aliases?
  • Have you ensured that names are kept relatively short, easy to remember and unique to avoid conflicts or confusion. Note that URL lengths including filename as are restricted to 260 characters

Extranet and Security Planning Needs

  • Have you considered and anticipated password and account support for nonemployees who access extranet sites?
  • Are there groups you need to deny at the Web application level?
  • Are there unique permission levels you need to apply to individuals or groups at the web policy level?
  • Are there unique or different authentication mechanisms you need to implement for extranet users?
  • Do you need additional Shared Service Providers to associate with your extranet Web applications?

Search and Indexing Planning Issues

  • Have you structured the content that needs to be indexed in terms of priority?
  • What information do you need to crawl and have placed in your index?
  • What content sources are needed to adequately crawl the information that needs to be placed in your index?
  • What will be the Full and incremental crawl schedules for each content source?
  • Do you have adequate server hardware to crawl all the content sources in your current schedule?
  • Do you have adequate bandwidth available between your index and your content sources?
  • For each content source, what rules, crawler settings and crawler impact rules are needed?
  • Who will troubleshoot failed crawls or information that does not appear in the index?
  • Who will evaluate the content sources so that the crawl criteria are configured efficiently?
  • What will be your search scope topology?
  • Do you need additional iFilters?
  • Do you need additional Protocol Handlers?
  • Do you need to add File Types to SharePoint?
  • Do you need to add icons to SharePoint?
  • Do you need to use OCR features?
  • Do you need special accounts to crawl certain content sources?
  • Do you need to create any Best Bets (2007 / 2010) / (Promoted Results 2013)?
  • Do you need to group any Crawled properties?
  • Do you need any special Server Name Mappings?
  • Have you established primary, secondary, tertiary and demoted sites for Relevance?
  • Have you ensured disks are optimised for Search?

 

Disaster Recovery Planning

  • Have you set deleted retention policies for the two-stage recycle bin in document libraries?
  • What are your plans for single site and site collection recovery?
  • What are your plans for server recovery?
  • What are your plans for farm recovery?
  • What are your plans for data-centre failover?

 

Staffing Needs

  • Do you have at least one architect who knows SharePoint at a granular level?
  • Do you have at least one developer who knows customisation at a granular level?
  • Have you provided excellent training materials and trainers for end user education?
  • For large indexing environments, have you considered a FTE for search and indexing?
  • To ensure robust taxonomy implementations, have you considered 1-N FTEs for content types?
  • To ensure robust customised scenarios and/or complex workflow, have you considered 1-N FTEs for application and workflow development?

 

Personalisation

  • Have you defined what Active Directory attributes you want to import from Active Directory to help build your profiles and audiences?
  • Have you defined what profile attributes you want to populate for the user’s profile?
  • What is the profile import schedule?
  • What is the Audience compilation schedule?

 

Document Library Planning Issues

  • How will you educate users to create document libraries based on a naming convention you propagate?
  • Where will you enable the require document check out for editing option?
  • Have you ensured that the number of documents in a view or folder are within best practice thresholds?

 

SharePoint Capacity Planning, Reporting and Monitoring

  • Have you run performance counters to establish a baseline of performance counters?
  • Have you accurately mapped your Web applications to your application pools?
  • Have you planned the managed paths for important web applications?
  • Have you estimated data requirements for SharePoint, ensuring you have enough disk space in your topology to accomodate growth?
  • Set database size limits by implementing Site Quotas plus Site Limits on the database
  • Have you established monitoring at the server, IIS, SharePoint and ASP levels and know what acceptable and unacceptable results are for each counter?
  • Have you considered using external tools for monitoring SharePoint and if so what are they?
  • Have you defined scheduled downtime periods for maintenance?
  • Have you communicated the procedure to report unscheduled downtimes?
  • Have you considered server redundancy, SQL clustering, Imaging and Windows Load Balancing if you need high availability on one or more SharePoint services?

Plan site quota templates

  • Have you defined auditing reports at the farm and site collection levels?
  • Have you established storage usage reports?
  • Have you established required activity reports?
  • Have you established SLAs for performance?

 

Branding and Consistency

  • Will you avoid making changes to site definitions when they can be made with features?
  • How will unique features be created?
  • What are the documented processes from which to create workflows?
  • What master pages will be needed for consistent navigation and branding?
  • What content types will be needed consistent metadata, site templates, and workflows across documents?
  • What rollup features, assemblies, and changes in solution deployment packages are needed?

Criteria for creating a web application

  • Does the group have unique security needs?
  • Does the group have unique information consumption needs?
  • Does the group have unique taxonomy needs?
  • Does the group have unique collaboration needs?
  • Does the group have personnel they can assign to site collection management?
  • Is creating the web application the right thing to do politically?
  • Does it make sense to create the new Web application?

Additionally, you should take a look at this:

User Requirements Checklist – this is a further set of areas that you will need to address which when completed gives you a better idea on user requirements. In my book – Managing and Implementing SharePoint 2010 Projects (which applies to SharePoint 2013 as well), I went into much more detail about these including a process to capture the results from each of the decision points (Chapters 4, 10, 11 and 12).

SharePoint Service Level Agreement Guide

SharePoint Service Level Agreement Guide

Support service development for SharePoint is crucial to ensure sustained SharePoint Governance and User Adoption. I had the situation where in building a SharePoint support service that a customer needed the provision of support to be handled differently for a newly delivered SharePoint solution, and also needed that to be documented and agreed by the SharePoint sponsor. The reason for this is that they needed the support service to be measured against the supply of support to that solution, which was critical to the department and the organization.

(more…)

SharePoint and the Internet of Things

SharePoint and the Internet of Things

Bold statement time. The Internet is a collection of machines – and there is more data generated by machines than humans. IOT (Internet Of Things) is connected devices providing data which will simplify, enhance, and enrich our lives. Already connected devices are beginning to revolutionise our lives; but to understand the nature, challenges and opportunities we need to understand how we can take informed decisions concerning this technology and trends.

Things like how the data our devices upload and download is shared, used, managed, controlled with clear data integrity. What should be our focus, what and who can help us understand this technology. IOT has implications for those working within the SharePoint sphere. As SharePoint workers, we will need to roadmap and further refine data provided  (from internally or externally provided systems harvesting sensor data) to define an IOT strategy.

We will need to learn how to promote use of devices used within organisations, so they become smarter devices thus turning our companies, and ourselves, into smarter people. The article I have written for TechNet, aims to describe, simplistically, the nature of IOT, some of the key opportunities realised by Microsoft and others, the challenges we may face in control, management, security, privacy. The article suggests some take-aways in what we may need to address to support the infrastructure and manage the data.

Sometime ago, I also wrote about the skill-sets coming into the fold of data analysis (the Data Scientist). We are already seeing the emergence of the CDO (Chief Data Officer) whose skillset will become more and more entrenched in helping people make decisions on data coming from sensor feeds and the management of IOT in organisations.

Even my kids know about IOT and sensor technology. My eldest daughter, an ardent follower of fashion, running her own shop, mentioned to me that she was really into reading up and working on opportunities concerning nano-technology in clothes, as she thought it definitely the future. I thought that nano-technology in clothes was a myth; that it simply didn’t exist (showing my age I suspect) – but I was astonished to find on IET an article talking about just that, even to the point where engineers were busy creating clothes and being designers! Imagine, nano-technology in clothes; that would be able to determine the colour and provide better waterproofing in clothes – wow…. Surely then, we can’t be far away from having our clothes change colour based on the time of year, or maybe even inform how many washing cycles clothes can take before needing repair / replacement? So that means sensor technology in clothes must be a reality…

Anyway, I just had to do more digging. I am sure there are implications from a systems analysis, and service delivery perspective, particularly for data management.  I found myself absolutely fascinated by the impact of IOT. From discussing with other techies in this field and more, I was able to put together an article which I’ve had posted to TechNet. Please go read the article here.

Delivering SharePoint Solutions – Areas of Importance

Delivering SharePoint Solutions – Areas of Importance

A challenge that SharePoint organisations have who are actively involved in the creation, then management, of SharePoint solutions, is then applying a process of delivering those solutions, and then using the same defined process. And note, we are not talking complex or simple SharePoint solutions, these solutions could be as simple as configuring a SharePoint site with repositories to provide a records management experience, or to provide a method of filling in on-line forms, or a business automation solution utilising workflow templates, or even taking on a third party app in a SharePoint 2013 online site, etc.

More often than not, those who do not apply any process involving any kind of systems analysis and design, then through to administration of SharePoint solutions usually end in disaster because:

  • The level of support provided is inadequate to the solution can be scaled
  • The deployment process has not been followed, for example, in an ‘on-premise land’, ‘let’s build the lot on production…’
  • It’s easier to start building the solution virtually identical to one already in use, than working from the design of another likewise solution, because it is not possible to locate the design for the existing solution.
  • Solution ABC is nothing like another solution whose focus is virtually identical and has been built from scratch

Some customers when quizzed speak of their alternatives to delivering a solution, and some are nothing short of astonishing – here are some examples – prepare to laugh:

  1. Get a third party organisation to put the solution in for us because we do not have the time to follow any delivery process – but we want to control everything and be able to support it ourselves
  2. Build a delivery process, show that there is such a process in place,  but don’t actually follow the process
  3. Let’s simply get on with it, build the lot in a ‘fly by night’ fashion, we will deal with all the issues as they arise

Ok, laugh over… Let us quickly see why alternatives have been addressed which simply do not work. The main reason appears to be that organisations find it difficult to build let alone understand a delivery framework surrounding SharePoint solutions. This may be due to having one person to provide the entire solution start to finish with no proper support, or a lack of skills concerning how to provision a solution (because their background is programming), or even that the current process does not map to SharePoint.

If you happen to work in an organisation where there has been SharePoint solution success; for example, you have been on or lead a team responsible for delivering a SharePoint comprising of a number of tools and services, you will be in no doubt that the following areas would have been addressed:

  • Service Testing
  • Deployment
  • Versions
  • Support

Conversely, you may have been in a situation where there was deployed a SharePoint solution which had failed because it had not addressed the above.

Am going to try to help out then. I am going to describe four areas which relate to the practical work required around delivering SharePoint solutions – every SharePoint solution being conceived must:

  1. Be Usable
  2. Be Repeatable
  3. Be Supportable
  4. Be Extensible

If any one of the above areas is not fulfilled then the adoption of that solution will fail.

For each of the four areas I will describe some actions that you should consider. The topics will be written in a way that is SharePoint version agnostic and generic and can be applied to your organization.

At the end of each section will be a Deliver Actions section which will show three areas of concern related to the topic:

  1. Implementation – what actions needs to be done to ensure that the relevant framework section is in place.
  2. Consumption – what resources will benefit from the relevant section and what resources should be used to help place the framework section.
  3. Administration – How you will ensure that the service delivery model relevant to the section includes an element of management. This will ensure the sustainability of the relevant section.

Please note though, describing these areas is not easy. I have even have difficulty amongst other solution architects in explaining the concepts, because of statements of SharePoint service delivery which is all over this article, and the fact that the areas covered in this article may touch all parts in an organization, which therefore increases complexity. So, to those new to SharePoint Service Delivery, as well as reading the guides, I suggest that you:

  • Get help. Seek a SharePoint solutions architect to help you meld the service framework to match your organisation resources.
  • Ensure that to back up the SharePoint framework that you have / using a methodology that allows the framework to connect to, that also allows a logical and structured approach. 

The areas being described are separate articles as follows – please read them (when they are available) and they will be listed and categorised on the site (when they are available):

My Books

My Books

I’m focused on SharePoint, having been involved since SharePoint 2003 hit the streets. All of my books are dedicated to SharePoint Implementation, Service, Support, Automation and SharePoint teaching. Click any of the links below to find out more about the books I have published:

Managing and Implementing SharePoint® 2010 Projects

MOS 2010 Study Guide for Microsoft® Office SharePoint®

MOS 2010 Study Guide for Microsoft® Word Expert, Excel® Expert, Access®, and SharePoint®

Microsoft® SharePoint® 2013: Planning for Adoption and Governance

Additionally, I was technical author for the following two books:

MOS 2013 Study Guide for Microsoft Office SharePoint

Creating and Implementing Microsoft SharePoint 2010 Real-World Projects

I am editor for the Software Best Practice Development Journal here.

SharePoint Archive Planning Guide

SharePoint Archive Planning Guide

History has a way of repeating itself. Thankfully, when we learn from the mistakes of the past, we are able to address new challenges more quickly and in smarter ways. In the early 1990s, email emerged as a collaboration mechanism, speeding up communications between multiple parties.

(more…)

Business Continuity

Business Continuity

Business Continuity is a management process that provides a framework to ensure the resilience of your business to any eventuality, to help ensure continuity of service to your key customers and the protection of your brand and reputation. In defining a SharePoint BCM it provides a basis for planning to ensure your long-term survivability following a disruptive event.

(more…)

Business Continuity

DRP Guide

Here’s a guide to Disaster Recovery and building a strategy . Disk crashes, power outages, communication loss-are all minor disasters that happen on an occassional basis – and most of us have a back-up plan ready to put into effect.

(more…)

Business Continuity

Developing a Contingency Plan

A contingency plan guide. Every company, and each of its locations, is susceptible to disaster. Disk crashes, power outages, communication loss-are all minor disasters that happen on an occassional basis-and most of us have a back-up plan ready to put into effect. But what about major disasters fire, flood.

(more…)

Business Continuity

Disaster Recovery Planning Framework

A great little template that can be used when working through a Disaster Recovery format for an organisation. – Excerp from the first paragraph: “It is proposed that each business unit be required to produce its own DRP, which will be integrated with the overall DRP managed by CEDRG. All recovery plans will need to take account of the role of the police in a disaster situation and make provision for a disaster occurring outside normal working hours.”

(more…)

Business Continuity

Guide to Business Continuity Planning

A good guide to Business Continuty Management is available for download. Business Continuity Management is a process driven from the top of the organisation. The first stage has to be an acceptance by the Board or the Executive Committee of the organisation that BCM is a valid approach to take.

(more…)