SharePoint Disaster Recovery Thoughts

Lately – the subject matter of SharePoint and disaster recovery has been an interesting one which I’ve had several discussions about in my various SharePoint travels. This is indeed a serious subject that many times is not thought out, nor planned – nor even tested or accounted for. However – in my view the opinion should be that as much time is spent in setting up and architecting a SharePoint site, this same amount of time – should be spent in thinking about a disaster recovery strategy.

I see two views on this matter – the first is what I will call the “poor version” of disaster recovery and this involves essentially backing up and then shipping offsite the SharePoint databases each night. This plan also would include shipping off the snapshots of the virtual machines as well – so that a server and database set can be restored if necessary.

The second view and more expensive model involves taking a back-up each night of the whole entire farm and then having that farms copy of assets go to a local storage hub as well as offsite. In this model when I’m talking farm – I mean the whole farm – virtual machines, databases, configurations, site collections, sites, document libraries and lists, etc. In this model if someone deletes a whole site – it could be recovered in full – regardless of the size of the site. Also if someone deletes a library or list it can be recovered. Additionally a policy under this model could be put in place to have the data be stored for 90 to 120 days – which would be double the standard 30 day – end user recycle bin and then 30 day administrator recycle bin – that is currently available.

Thus, this is a broad topic but my goal is short posts to get you thinking!

Project Methodology - Waterfall vs. Agile for SharePoint Projects

In regard to project management methodologies and SharePoint – for a long time I utilized a pure Waterfall methodology where requirement analysis, system design, implementation, testing, deployment and maintenance was done. Since a large majority of the SharePoint work I’ve done to date involved migrating content from one system to another or from one SharePoint version to another – this methodology appeared to work well in these projects – however pros and cons were evident. Essentially since content always needed to be reviewed the requirement was well known it was move content from this SharePoint location/version to this SharePoint location/version. At the system design phase – the Waterfall and SharePoint do work a majority of the time because it is known what the said systems base will be utilizing. The only aspects from a systems standpoint is that from one version to another – different features typically needed to be turned on to support needed functionality. Great example being site publishing. Testing using Waterfall – seemed to always be slow as test scripts either needed to be written or a load test needed created in the designated application (example: Load-runner, Team Foundation Server, Stress Stimulus etc.) Additionally, deploying using Waterfall seemed to produce a fair amount of documents surrounding lists of various items that needed turned on, configured for, migrated, moved etc. Then maintenance using Waterfall – really always seemed to leave a lot to be desired as guess work into what was really being asked for a lot of times – resulted in sites and subsites that didn’t meet user’s requirements and thus – had to be scrapped.  

Now coming to age – it appears SharePoint and an agile project methodology – work well. The notion of creating work that is broken down into 5, 10, 15, 30, 60, 90 day sprints is ideal.  For the larger work an epic – usually work that spans a quarter (or 90 days) works well for SharePoint because typically this is how long the complex world of SharePoint to migrate a site or create it – spans if all the bells and whistles of content analysis, design, graphics, training and testing are to occur.

An example of an epic maybe: [SharePoint 2016 – IT Site]

A feature which would be a core item that needs to be included in the project and associated with this epic maybe: [SharePoint 2016 – IT Site] – Create IT site

Stories are core working pieces that need to be built and are part of a feature – so example items are:

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT project list page

Tasks will then appear under each story so in this example case these would be:

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Therefore putting this down on paper with the epic/feature/story/task – the project mapped out would look as such where the indenting depicts where the item fits in regard to this methodology:

[SharePoint 2016 – IT Site]

[SharePoint 2016 – IT Site] – Create IT site

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list page

 [SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Thus, it’s easy to see why the Agile methodology lends itself to SharePoint in a much broader way – as features, stories and tasks can be created as the project itself evolves. Since SharePoint lends itself to creating sites of business value – by using an Agile methodology users will have real working sites with the needed requirements more quickly and can therefore, change items as needed as the sprint progresses. Because of this – I’ve found that Agile is a better project methodology choice for SharePoint projects then Waterfall.

SharePoint - Public vs. Private Site

An overview of public vs private sites.

Public Sites – A site referred to as public will by default be available in a read only format to all users whom have access to the said Internet or Intranet site. The home page of the Intranet is an example of a public site.

Private Sites – A site referred to as private will only be available to those users whom have been granted access. Such sites will contain team collaboration information which should be shared only to applicable users. An example of a private site would be an IT Private Site which would contain content and diagrams which only IT team members would be able to see and collaborate on.

Overall, a good rule of thumb would be to have a private site created and available for applicable team members to create master content in (example as a .doc or .docx format) – then if such content is to be viewed on a public site – it should be created as a .pdf then uploaded/moved to a public site. This way, master documents are kept on the private site – then only posted in a .pdf format to a public site when content is to be shared to a wider audience.

SharePoint Definitions - Common

The below are some common SharePoint definitions that are often asked:

Active Directory - a directory service from Microsoft utilized in SharePoint for grouping user login accounts in named groups.
Activities -  tracked updates related to a specific user. They are often related to the users social interaction within SharePoint (such as tagging, rating, etc).
Check-out: To lock a file while editing it to prevent others from overwriting or editing it inadvertently. Only the user who checks out a document can edit the document.
Content Type - a named and uniquely identifiable collection of settings and fields that store metadata for individual items in a SharePoint list. One or more content types can be associated with a list, which restricts the contents to items of those types.
Document Library - a configurable list in which documents and folders can be stored. The document library has special settings above and beyond a folder such as versioning settings, workflow settings, and information policies.
Follow - ability to subscribe to receive that user’s updates.
Hash tag – way to organize tweets. Users simply prefix a message with a hash tag to enable others to discover relevant posts. One commonly used hash tag is to utilize a user’s name example #Kevin O’Neill.
Home Page: A Home Page is the main page of a SharePoint web site; it provides a navigational structure that links the site components together. The home page has two major navigational areas: the top link bar and the quick launch bar.
Library: A library stores files as well as information about files. You can control how documents are viewed, tracked, managed and created in libraries.
List: A list is similar to a library, except that it is a collection of information where a team or department can store, share and manage information (not files).
Metadata - data about data. Metadata describes how and when and by whom a particular set of data was collected, and how the data is formatted.
mySite/OneDrive – a single page portal that contains the user’s personal sites, links, etc. My Site consists of both a public and private view. The private view is intended as a personal workplace for the individual end user. The public view, on the other hand, acts like a business card that can be accessed by other portal users.
Page – used to display or summarize information and links within a site or sites.
Public Site - a site created in SharePoint which is available to all users as well as the information it contains is relevant to all users.
Private Site - a site created in SharePoint which is available to targeted designated users as the information it contains is relevant to only members of a said team or project.
SharePoint Designer - a tool which allows administrators to modify pages, and customize their SharePoint sites in more powerful ways than the out of the box graphical user interface.
Site - a complete web site stored in a named leaf of the top-level Web site.
Subsite - a named subdirectory of the top-level Web site that is a complete Web site. Each sub site can have independent administration, authoring, and browsing permissions from the top-level Web sites and other subsites.
Survey - a Web site component that enables users to respond to a set of questions specified by the creator of the survey. Results are tallied in a graphical summary. Surveys provide a way to poll portal users for input on a subject. Surveys support a wide variety of response types from simple Yes/No answers to free-form text.
Tag - keywords that are assigned to content. Tagging pages to share with others is social bookmarking.
Term Set – a designated listing of metadata tags to be utilized for a particular area, department, project or initiative.
Versioning: The process of creating a numbered copy of a file or an item whenever a revision is saved to the library or list.
Web Part: Web parts are basic building blocks of a web part page. A Web Part can be reused, shared and personalized by all users who have permission to access it.
Web Part Page: a special type of page on a SharePoint site that contains one or more web parts.
Workflow - the automation of business processes, where business documents and tasks are passed automatically from one user to another for action, according to a set sequence.

SharePoint 2013 Survey Word Wrapping with CSS

The other day – I had a user request asking how in a SharePoint 2013 survey – it’s possible to turn word-wrapping on – in regard to the text in questions?

So knowing that the master page being utilized was customized – I cobbled through some search sites and found bits and pieces of what was needed to obtain the text wrapping.

Therefore, to fully implement this – here are the steps to follow:

1. From the opening page of the survey whose page is overview.aspx click the Respond to this Survey link.
2. Then from the Gear select Edit page -> click the link Add a Web Part -> Media and Content -> Content Editor -> click Add.
3. On the right hand side – click the drop down arrow and select Edit Web Part:
   
4. Place the cursor into the content section of the web part
    -> in the ribbon select Edit Source.
   5) Copy and paste in the code below into the window and click the OK button
   <style type="text/css">
   .ms-formlabel, ms-vb nobr {white-space: normal; width:660px;} #MSOZoneCell_WebPartWPQ2 .ms-formlabel {word-wrap:break-word;}
   </style>
5. On the far right hand side under the Content Editor properties expand the Layout then place a checkmark next to Hidden:
6. Scroll down then select on the right hand side – Apply then OK.
7. Click in the ribbon the Page tab -> Stop Editing -> Stop Editing. The first page of the survey provided the code was entered correctly should now display the word wrapping.
8. If the survey has page separators meaning it will have more than one page – then click Next.
9. Repeat steps 2-7 for each page separation and now word wrapping will be present across the full survey.

SharePoint 2016 Server Preview Installation

https://www.amazon.com/dp/B015AOY2CM


The SharePoint world is always exciting and installing SharePoint is always filled with wonder on what will occur during the setup. In this guide a real world step-by-step of what was done and happened when installing a SharePoint 2016 preview edition on a single virtual machine are reviewed.

SharePoint Skill Sets!!

SharePoint skills are so varied across the board – I’ve found – that since SharePoint is in
my view the world’s biggest jigsaw puzzle – that business users and technology
individuals need to play nice and understand the pros and cons of what is the best
scenario for a given situation.
That being said – I’ve learned a fair amount the last few years or so I’ve been involved
with SharePoint on the intricate nature of SharePoint via many scenarios.
The varying degree of user’s knowledge makes everyday a challenge for all of us whom
run a SharePoint farm. I know from talking too many that some users have good working
knowledge of SharePoint and can edit pages without incident and add and know what a
web-part is. Other users we can agree need to be told step by step or just rely on content
editors to do simple tasks even though they are indeed content contributors.
Thus, it’s a known fact with even with constant screen shots and education classes made
available – it’s a lot of times a lost cause.
Moving up the ladder – the same holds true for those that claim they are SharePoint
developers or SharePoint administrators. In my travels – some whom claim they are.
SharePoint administrators can only do basic content entry and permissions. The notion of
server maintenance and editing a web.config is taboo. A good SharePoint administrator in
my view should know how to configure webparts, create web applications and site
collections with ease and be able to fully run the SharePoint farm architecture amongst
other items.

In SharePoint developer mode the same holds true – individuals whom take third party
web parts and configure them consider themselves developers. In my view a good
SharePoint developer knows the full SharePoint object model, C#, SQL, the SharePoint
farm and advanced architecture techniques.
Thus, in conclusion – this topic opens the door for a fair amount of conversation and
panel discussion material. It can be stated that with better defined job descriptions and
education of the SharePoint jigsaw puzzle that the SharePoint community as a whole will
be better.
If so desired feel free to contact me and we can talk more on this subject :)