The SharePoint Proveloper

I am a SharePoint Proveloper, a new hybrid of a SharePoint Professional (aka Admin, Infrastructure/Systems Engineer) and a SharePoint Developer.  You may be one too.

Traditionally, someone working on a SharePoint system falls into one of the two distinct camps of Professional or Developer.  Yes, there are other SharePoint roles too, but the emphasis of the Proveloper is on these two areas.  When working in the SharePoint space, there is a lot of jest that ‘that is a system problem’ or ‘I am not a developer’ between the two sets of parties.  As an ‘infrastructure guy’ myself, I am guilty of having used some of these lines from time to time.

However, the more I work with SharePoint the more I see a blur between these divisions.  From a SharePoint IT Professional’s point of view, it is important to understand certain aspects of SharePoint development.  Understanding of these aspects can lead to better outcomes for the SharePoint IT Professional, and turn them into becoming a SharePoint Proveloper.

Although my perspective is one-sided, I imagine the converse also applies.  Usually a SharePoint Developer has little concern for the underlying platform supporting SharePoint.  With a deeper understanding of the infrastructure fundamentals, it can lead to better outcomes for the SharePoint Developer, and turn them too into a SharePoint Proveloper.

For the remainder of this post, I wish to focus on the SharePoint Professional, and look at why it is important to understand different aspects of SharePoint development.  This is heavily influenced by my own background.

Here are a few reasons why it is important to have these skills and know something about SharePoint development, from the viewpoint of a SharePoint IT Professional:

The SharePoint Proveloper: Conversations

Probably the most important advantage of being a SharePoint Proveloper is the ability to have informed conversations with others.  The advantage of knowing different aspects of development comes by having more knowledge around how SharePoint operates and how SharePoint can be extended. When talking to people within the organisation, the business users, a SharePoint Proveloper knows to some extent what may or may not be possible.  In turn, the SharePoint Proveloper can have conversations with the development team and explain business needs in an informal business analyst capacity.

The conversation continues between the SharePoint Proveloper and the developers.  The SharePoint Proveloper will need to understand how custom built solutions work when deploying them to the farm.  They also need to be able to discuss topics such as availability, security and capacity and understand the impact a custom solution may have to a SharePoint environment.

The SharePoint Proveloper: Deployments

In some organisations, custom solutions are deployed by the development team.  In other organisations, custom solutions are deployed by the infrastructure team.  The solution may be a third party product, requiring someone to deploy it into the SharePoint farm.  The SharePoint Proveloper needs to have skills to handle this process, and also how to handle it when things do not work.

When working with iherb promo and custom solutions, the SharePoint Proveloper is going to need to understand things like the Global Assembly Cache (GAC), a place where compiled code (.dll files, also referred to as binaries) is stored and registered for Windows and other applications like SharePoint to use.  This also ties in with understanding the relationship of web.config files and also artefacts that can be deployed to the SharePoint hive.

The SharePoint Proveloper: PowerShell

For anyone working on SharePoint, PowerShell scripting is a mighty tool to know how to use.  The strength of PowerShell is to perform and automate tasks that are usually done in the GUI.  Every SharePoint Proveloper needs to know PowerShell.  It is not limited to just setting up and configuring a SharePoint farm, but also useful for performing site administration as well.

Sure, a lot of SharePoint Professionals may know some PowerShell.  To try and position the amount of PowerShell knowledge a person may have, I would say there are three levels of ability that someone may have when using PowerShell for SharePoint:

  1. Able to use cmdlets to achieve simple things.  Usually single lines and may compose simple scripts.
  2. Extends to use the SharePoint object model and generates functions within scripts.
  3. Utilises .NET classes and reflection.  Writing complex and well structured scripts.

Level 1 tasks are a great way to start.  With this knowledge, a person is able to manage services, web applications and farm configuration with one-line commands and this is extremely useful.  As knowledge grows, a person starts to understand the SharePoint object model (what SharePoint Developers use).  With increased understanding of how it works, a person is able to leverage it to achieve many everyday tasks.

With having this level of PowerShell knowledge   I’ve been able to create scripts that would otherwise require a developer to achieve tasks such as:

  • Manipulate simple branding elements across hundreds of sites in a farm
  • Upload documents via SharePoint web services
  • Apply permissions in a structured manner

If you are reaching level 2 status, this is a good thing and in the realms of being a SharePoint Proveloper.  Level 3 tasks require direct calling of .NET classes and using reflection.  I will not say I am there yet, but many of my Developer friends do on occasion call these object directly with PowerShell.

The SharePoint Proveloper: Troubleshooting Problems

Another reason why you might be a SharePoint Proveloper is if you have advanced troubleshooting skills.  Unfortunately no SharePoint environment is ever perfect, and problems will seemingly always present themselves somehow.  As a SharePoint Professional, you may already be familiar with the SharePoint ULS logs and the Windows event viewer.  These are quite useful places to identify a lot of issues.  However sometimes these do not capture everything that happens in a system.

In addition to SharePoint, other possible problems can occur with IIS, custom web services, the SQL database, and the client’s browser.  This is before you may need to investigate traditional IT infrastructure such as Active Directory, Exchange, the virtualisation platform, networking equipment and underlying hardware.  Being able to investigate all aspects of SharePoint certainly is useful for a SharePoint Proveloper.

Are you a SharePoint Proveloper?

Take a moment to think about what makes up a SharePoint Proveloper.  At its simplest form, it is someone who has key skills in either the area of SharePoint Professional Administration or SharePoint Development, and has a good understanding of the other.  I certainly feel I am a strong SharePoint Professional.  Even though I would struggle to develop a web part to say “Hello world”, I know enough that I can talk to Developers about custom solutions, perform deployments, write complex PowerShell scripts and diagnose issues with SharePoint.  I am a SharePoint Proveloper.

Reflect now on your own experiences.  Do you think you are a SharePoint Proveloper?  If you feel you are a SharePoint Proveloper in some way, please share your perspective in the comments section below.

SharePoint People Matches Was My Idea!

Microsoft SharePoint 2010 has dramatically improved since its predecessor, and the one thing I wanted to mention was the related people matches.  In SharePoint search now, you can configure the results to show people who are related to the content you are trying to search for.

This really is a great little nugget within SharePoint, because it is one that works to connect people who have tacit knowledge – knowledge stored inside people’s heads, and may not be explicit in any other format.  People can be profiled based on their search queries, their profile, and their activities within SharePoint.  Connections are able to be made as to who may be a person with some knowledge pertaining to a particular search query.

The only problem is, this all seems too familiar.  It seems I’ve seen something like this before…my final year university thesis!

My thesis, TIXS: Tacit Information eXchange System: An investigation of electronically developing and exploiting tacit knowledge in communities of practice, was developed to perform what I explained above – connect people based on profiling their search behaviour, and afford the transfer of tacit knowledge.

All be it a much simpler implementation to the feature in SharePoint Search, it is essentially the same concept.  Until someone else speaks up, I’m claiming that it was my idea first!

Security Concerns on SharePoint 2010 HR Site

A few weeks ago, I was approached by our HR department to advise how to best secure the personnel files inside SharePoint. There were some concerns that a number of staff (IT and non-IT) who had unncessary access to this data. So I outlined for them our structure, who had access at each level, and them some options to mitigrate their security concerns. The HR executive understood that it would be impracticle to totally remove IT staff access from accessing personnel files, but agreed that it should be limited.

Current Scenario

The current structure of the INTRANET is along the lines of:

(1)SharePoint Farm:    COMPANY FARM
(2)Web Application:    |__INTRANET
(3)Site Collection:       |__Human Resources
(4)Site:                  |__Human Resources Site (root of site collection)
(5A)Site (subsite):          |__Management Tools
(5B)Site (subsite):          |__HR Only
(6)Document library:            |__Personnel Files

Let’s look at how we can give acccess to the Personnel Files (6).

  1. At the lowest level (5B), a Site typically has the permissions defined in the Owners/Members/Visitors SharePoint groups. Removing access at this level, will block access for the majority of staff. Even with Visitor access at the top level site (4) we can prevent access to the lower sub-Sites (5B).
  2. At the Site Collection level (3), there is an overriding group called Site Collection Administrators that effectively have access or the ability to grant access to all content below it, including the HR Only Site (5B).
  3. At the Web Application level (2), we have a user policy defined, which gives a group of people full access to ALL site collections (eg Human Resources, Operations, Sales etc) and all Sites (inc HR Only (5B)).
  4. At the top most level (1) there are Farm Administrators. The role here is to manage the SharePoint infrastructure. These people, although they may not have explicit access to any Web Applications (2) or Site Collections (3), they are in a position to grant access to themselves or someone else. It will be impossible to not have some IT staff assigned at this level. There are no options to restrict Farm Admins from changing permissions.

In my original communication, I included a list of staff who had access, and it was quite clear there was an abundance of people with access at the latter to levels – (1) and (2) which is what gave most concern to our HR department.

Mitigation Options

  1. Enable full auditing on the HR Only site to record who has accessed information
  2. PRO: Quickest to achieve, will not require an internal approval processes (treated as BAU).
    CON: Won’t prevent access, will require monitoring from HR to review audit reports.

  3. Trim the people with access as a Farm Admin, within a Web Application User Policy and Site Collection Administrators for Human Resources.
  4. PRO: Quick to achieve.
    CON: Will require staff who do have permission to perform more administrative functions, will require a submission for approval.

  5. Create a separate web application just for HR and restrict Web Application User Policies and Site Collection Administrators
  6. PRO: Moderate effort to achieve, should be able to move existing content without a lot of rework.
    CON: Farm Administrators can still grant access to themselves or others, will require a submission for approval.

  7. Create a separate SharePoint farm for HR-INTRANET. Least amount of non-HR priviledges can be granted to this farm, and lock down the IT staff access.
  8. PRO: Most secure option, does not impact administration effort for INTRANET, should be able to move content across without a lot of rework, can provide a seamless transition between INTRANET and HR-INTRANET, can share some service applications across farms (eg managed metadata).
    CON: Most amount of effort to achieve initially, will require a submission for approval.

I suggested that if HR is happy that auditing will be sufficient to monitor access to the HR Only site, then mitigation option 1 would be recommended.

However if it is not sufficient just to know who has accessed Personnel Files, then mitigation option 4 would be suitable for a complete, separate HR SharePoint farm.

Site auditing was enabled as an immediate measure, and a proposal was submitted to proceed with the provisioning of a dedicated HR SharePoint farm. At the time of writing this is still awaiting approval.

Building the SharePoint House

I’ve been working on a SharePoint 2010 project lately, a migration from a SharePoint 2007 farm.  As usual in this particular organisation, there is never any time for any actual planning, but a desire to just trial and error it.  The only problem is, it has suddenly become production, and I’ve getting bogged down helping various people with site specific requests, rather than completing the infrastructure configuration (don’t even get me started on the user profile synchronization service…).

To help explain why everything is not yet configured, or why I have to keep performing IIS resets on the farm, I’ve been using an analogy to the staff who are coming to me – I call it the SharePoint House.

SharePoint is a big block of land, and we’re building a house (web application) on it.  Let’s call this house Portal.  Portal from the outside looks like a completed house – the foundations are down, there’s a roof, and we have a few rooms (site collections).  Some of these rooms have wardrobes or even other rooms contained within (sub-sites).

Within some of these rooms we have special functions (features) like a kitchen vs a bedroom, and they all have different looks and feels (theming, page layouts).  Inside the rooms, wardrobes etc is a bunch of storage items – drawers, cupboards, boxes – these are used to store stuff (libraries/content) and some of it may even be collated together to represent something in particular (content types).

Of course, no house would be complete without running water, electricity, gas, cable TV etc all connected up (service applications).

So when someone asks me questions or complains about the Portal, I explain the SharePoint House.  I then make a point that we didn’t use an architect to design the SharePoint House, we just started building.  Then all of a sudden, while we were still putting up rooms, everyone all of a sudden started moving in.  In the chaos of moving all their own stuff across, it was poorly organised and now hard to find.  To make matters worse, when anyone went to use the toilet…it wouldn’t flush.