As a SharePoint admin-to-be, I spent the weekend trying to understand what it actually is. My first task is to write up a coherent explanation of SharePoint 2013. After trawling through hours of pseudo-technical marketing jargon, I decided the best way to learn is to just go through the site options myself. Anyone with an account and a couple of spare hours can do most of this.
The first thing to note about SharePoint is that it’s an object-based system – if Web Applications, documents and users are Lego bricks, SharePoint is the Lego board on which they’re put together. SharePoint is a platform on which Web Applications are assembled in a structured way to deliver a service. Sites themselves are constructed by putting together components known as ‘Web Parts’.
Maybe this is a slightly patronising way of describing it, but there’s a reason why it’s important to view SharePoint as an object-based system. What’s also important is that users get away from thinking in terms of files and directories, and start viewing documents as objects with attributes.
Sites and Site Collections
While SharePoint can be considered an advanced Content Management System, there are some differences. An organisation using SharePoint will have a master, top-level, site. Added to this are multiple sub-sites. Or perhaps there’s a Site Collection for each department, with a site for each team or business unit. Each Site Collection has an administrator, to distribute the task of managing the whole thing.
Remember the point about SharePoint being more a Web application platform? A site consists of ‘Web Parts’, each being a discrete component that performs some kind of page function – maybe a links container, calendar, a list of files or a blog entry. Web Parts are generally deployed at the Site Collection level, and can be re-used across sites for consistency.
The primary reason for encouraging the use of SharePoint is better document management, and to make documents easier to find. If, for example, meeting notes from six months ago had to be retrieved, it might be like searching for a needle in a haystack where a directory containing hundreds of files is concerned.
SharePoint solves this problem by attaching metadata (or attributes) to each document, so queries and filters can be applied to a document list. The standard Microsoft Word (and LibreOffice) file already has some of these attribute fields as the document properties – with Document Library attributes, it’s simply a matter of attaching additional fields to this.
As SharePoint permissions are based on Active Directory here, files and folders are more like objects – their permissions are inherited. In order to create a private library that’s only accessible to selected users, we must therefore break that inheritance before setting new permissions.
Every SharePoint user should be able to set up their own Document Library. Demonstrating with my personal site, I start off with the default Document view. One of the first things to do is add the metadata/property fields, so attributes can be assigned to each document.
Click the LIBRARY tab, and the Office-type ‘ribbon’ menu will appear along the top. In this, we want the ‘Library Settings’.
In the Settings page there’s a section for columns. By default they’ll include the properties that are already standard for Microsoft Office documents, but the chances are we’ll want to add more by creating extra columns. For example, we might want a property for subject area and document type. This could later be useful for anyone who wants to, for example, search for documentation on a specific project.
Since I’ve added a property field here called ‘Document Type’, I can now use that to filter my document list.
To the left of the search box, there is an option to Create View. The views are just different ways to display the contents in a Library.
New files can be created from templates within SharePoint. This will open the Office 365 editor, and the document will automatically be saved in the Library. Templates can be added as ‘Content Types’.
Most people don’t bother with static sites unless they have to. In my workplace it’s common for us to ask around, and email each other, for information that’s already posted somewhere on the portal, and we know that most people use web browsers to communicate rather than to view stuff. This is why ‘social’ media is more effective for drawing attention to something or other.
With SharePoint 2013 all users should get their own personal site, and the opportunity to interact, collaborate, contribute and otherwise become involved in whatever content is hosted. As we can see, it provides an internal ‘social’ network. What better way to facilitate ‘knowledge sharing’ and searching for expertise?
The personal space is accessed by clicking the user’s name at the top-right and ‘About Me’. Initially it looks a bit sparse, but other ‘Web Parts’ become available after sorting the ‘edit your profile’ page.
SharePoint and Team Foundation Server
One of the problems now is I’m administrating a site for a DevOps department, not an average sales or admin team, and we’re already using Team Foundation Server as our collaboration thingy. A couple of people have already been asking whether it’s possible to integrate the two. Technically it is possible.
In the Team Foundation Server Administration Console, we can see there are a couple of SharePoint options. One of them takes us to the SharePoint Extensions Configuration Wizard.
The other option is to set up SharePoint Web Applications. I’m assuming these are the applications to be embedded in a SharePoint site for displaying things from TFS. Here the service accounts of the web application and the main SharePoint site are registered so they can access the TFS resources.