Perficient Digital Transformation Blog


Richard Taylor

Twitter @SLKRCK

Posts by this author: RSS

Age old question: Buy or Build?

As I often come across in my engagements at Perficient, there comes a juncture where the client must make a decision between whether to pay us to write a custom application or purchase software that satisfies some business requirement(s).  Depending on who I am working with, the conversation typically goes one way or the other…adamantly.  If I am with a developer, the consultant will go right into a discussion about how he/she will be able to satisfy the requirement (and sometimes attempts to elicit requirements right there).  If I am with a business analyst or architect, the consultant will suggest several packaged software solutions that will satisfy the requirement.

The Triangle of Truth

When it comes to software development, there is an adage that states: you can have one or two of the following three attributes of your software solution, but not all three:

a. Quality

b. Speed

c. Robustness

If the client opts to have us write the application, that in and of itself, becomes a completely new project.  Estimating the cost of application development is a science and sometimes a complex one.  There are ways to keep a handle on costs, of course, and protocols and practices to keep it all in check.  But no matter how you slice it, it will cost time and more money in the long run.  The biggest things that worries me when the client opts to have us develop the solution is “Who will support the code after we are gone?”  When systems get upgraded, will the code be upgradeable?  I get uneasy especially around the time the platform is due for a rehaul.

It’s a much easier route if the client opts to have us give them demos and pricing for various packaged solutions.  This route takes care of the code supportability.  And sometimes…sometimes ends up being a less costly method.

There is certainly no one easy answer for all situation.  It comes down to which points on the Triangle of Truth are the sharpest.

Tips for Installing SharePoint on a Windows 7 laptop

​One of the things that can come in handy for a SharePoint consultant is to install SharePoint on one’s personal laptop. I speak at many conferences and sometimes do not have the luxury of an internet connection to a virtual server and my laptop only has 6GB of RAM, so a virtual machine running on my laptop would be a *D-O-G*. The other two options I have, then, are installing Windows Server 2008 R2 on my laptop (not happening), or installing SharePoint on my Windows 7 OS.

First you should know that SharePoint is very picky about its underlying OS and some things don’t work as they would normally under a server OS. That said, here are four things you should know about running SharePoint on your Windows 7 laptop.

1. Don’t install PowerShell v3 – If you are anything like me, you drool when you see things like ‘CTP’ or ‘RC’–the opportunity to play with technology before it’s fully baked and have input into the final product is awesome–however, when you need to demo in front of customers or get work done, sometimes you gotta leave that stuff alone (or at least put it somewhere where its harmless). SharePoint is a .NET 3.0 product and can’t deal with .NET 4. PoSh v3 is .NET 4.0 and if you installed it on your Win7 box and then put SharePoint on it, you are in for an ugly existence. None (NONE) of your powershell cmdlets will work. So what do you do? You’ll have to run PowerShell in v2 mode by typing powershell -version 2.0 at the PoSh prompt. This will run the current session in v2 mode and you can do what you need to…mostly. :)

2. Install SQL Server Management Studio Express (SSMSE) – Unless you install full blown SQL Server on your Windows 7 laptop (why?), you will need to be able to manage a database or two and to do that you will need to install SQL Server Mgmt Studio (SSMSE) so that you can do that. Oh, and another thing–you will be installing SharePoint as a STANDALONE installation, that is why you will get SQL Server Express. You can’t do a FARM installation because what will happen during the PSCONFIG stage as you specify the farm account will be SharePoint giving you the finger of scorn saying that “local accounts are not supported in a farm configuration”. Well…dang…its a Windows 7 laptop and unless your laptop is joined to a domain and you are connected to your network and have logged into the domain…you aren’t going to get very far. You will need to use a local account to get past here which means STANDALONE.

3. Make sure you edit the config.xml file before installing SharePoint — If you simply try to install SharePoint from the DVD onto your Windows 7 laptop you will get the virtual ‘Heisman’ ; telling you that your OS is not supported. To get around that, you need to first extract the files from the OfficeServer14 executable into a directory or copy the directory tree of the DVD to a folder and then navigate to \Files\Setup. There you need to edit the config.xml file. The highlighted section below is what you need to add to the file to make it work.


4. Create a script to start and stop SharePoint services – Like I said before, I only have 6GB RAM on my personal laptop which SharePoint loves to monopolize. When I am done with SharePointing and need to get to other things (like Zune-ing while blogging) I want to put SharePoint to sleep until I’m ready to get back at it. To do this, I *could* type services.msc at the run command and manually go through each of the services and shut them down–OR, I could set them all to MANUAL and then write a simple batch file that starts them when I want and stops them when I want. Here’s a tip: start the SQL services first and then the SharePoint services and the reverse that when you stop them.

SharePoint and Identity Management–Part 3 of 3

In the last post I touched on a few things: Authentication and Authorization (AuthN and AuthZ), Kerberos Authentication, and Claims Based Authentication and how they all have a role in Identity Management.  In this final post of the series, I talk to Role Based Access Control (RBAC) .

Access Control

The rules that define what a user can access are essential to enumerate in a comprehensive Identity Management system.  In some higher security systems, the rules not only define WHAT a user can access, but also WHEN and sometimes from WHERE. Most of the time we are referring to something like an Access Control List (ACL); but using ACLs can become cumbersome when we are dealing with LOTS and LOTS of users and managing ACLs for LOTS of users (or groups) can create chaos—especially if there are conflicts.  This is where we want to talk about Role Based Access Control (RBAC).


First, let’s set the vocabulary straight:

• Users—An entity that uses the system
• Roles—A job function within the context of an organization
• Permissions—Approval to perform an operation on one or more objects.
• Object—Can be many things; for example, an entry in a target system (such as an account), a network resource (a printer), an application (a procurement), a policy (password policies), and so on.
• Operations—Various and unbounded but including customer-defined workflow processes such as a password reset, the addition, modification, or removal (deletion) of user accounts, and specific data about them.

Users do many things and in a system such as SharePoint this can mean that users perform certain actions in one area, but different actions in other areas.  WHAT that person can do wherever they are doing it depends on the *ROLE* that person has in an organization.  Certain roles will have permissions granted to them.  You generally don’t want to have to give permissions to each object because then you would be returning to using ACLs which is a bad thing.

Below is a diagram of how RBAC could be used in a SharePoint implementation:


By assigning roles and giving the roles the access to do what they need wherever they are works much better than putting access on the objects and fretting about if someone needs access to it or not.

PowerShell for SharePoint Admins: The REAL Primer – Series #4

This is the fourth entry of my PowerShell for SharePoint Admins series.  I am basing this series on what SharePoint Administrators have said are the most important tasks to accomplish in PowerShell.  Here is the list:

  1. Create/Delete Sites, Webs and Web Applications
  2. Backup and Restore Sites, Webs and Web Applications
  3. Deploy Solutions and Features
  4. Add/Delete Users
  5. Logs
  6. Configure Service Applications
  7. Manage Content Databases
  8. Manage Timer Jobs
  9. Manage Content Deployment
  10. Manage Search

In this session we are continuing on in our quest to become proficient in this shell language.  So now that we’ve created a SharePoint site in our last session, we need to do what every responsible administrator should do: back it up.  Now HERE is where there is no denying that PowerShell is the way to go.  Even for us OSITAs…you *can’t* say that PowerShell in this case isn’t the preferred method (well, you *could*, but you’d be lying).


SharePoint security using the OSI model

I recently attended Microsoft Tech-Ed 2011 and had the chance to sit down with Mike DeVerter of Rackspace, a Perficient partner, after I presented at the conference about the 10 Immutable Laws of SharePoint Security. In this presentation, I talked about SharePoint security using the Open Systems Interconnection (OSI) model as a guide, covering where security lies in the OSI model. As SharePoint administrators, we think about permissions, authentication and authorization, but how often do we think about the ways in which we’re vulnerable outside of SharePoint?

Jeff also blogged about our interview here.

You can read notes from the presentation here.

SharePoint and Identity Management – Part 2 of 3

So last week we briefly touched on the characteristics of a good IdM solution or at least an environment that was IdM hygienic.  Some of those characteristics included the following:

  • View, create, modify, and delete users
  • Change passwords
  • Add or delete a user in a security group
  • Approve or reject requests
  • Delegate all permissions

This week I will talk a little about   AuthN and AuthZ from a SharePoint perspective (actually everything I talk about in my blogs is from a SharePoint perspective–very myopic, perhaps).


Authentication is the concept of: “I am who I say I am” and I prove it with something that only I would have or something that only I would know.  In SharePoint, typically, getting access to it means that you must provide your username and password combination; a combination that only you should know.  Authentication is a multiutilized word in SharePoint; Forms-Based Authentication, Claims-based Authentication, Classic-mode (NTLM)Authentication, and even Kerberos Authentication.  Let’s give a primer on each.

Kerberos Authentication

Kerberos is a protocol as much as it is a method for authentication.  I won’t go into the history of the protocol here, but from a SharePoint perspective, again, Kerberos is the system that grants tickets to clients, at their request, for access to services.  The name comes from the three-headed dog that guarded the gates of Hades.  The three heads are represented by a) The Ticket-Granting-Service (TGS); b) The Authentication Service (AS); and c) The Key Distribution Center (KDC).  If the client proves to the KDC that they are who they say they are and the client is correctly configured with a Service Principal Name (SPN), the AS will issue a ticket-granting ticket (TGT) using the TGS and then uses the ticket to access resources.  In the SharePoint world, Kerberos is the preferred authentication scheme but is more restictive in that a) you *must* use port 80 or 443 if you want the crawler service to crawl your content and b) You must use Service Principal Names (SPN) for the web applications which consume content on the same server where the content resides.


SharePoint and Identity Management – Part 1 of 3

I’ve been speaking recently at a multitude of SharePoint Conferences.  It’s an honor to be asked to speak at these conferences and to be recognized as a SharePoint expert.  Because I attend so many of these conferences, I see a lot of the same speakers–typically speaking on the same topics that they are comfortable presenting.  Lately, however, I have noticed that the topics are slowly shifting toward integration:  SharePoint with Oracle; SharePoint with SAP; SharePoint with eDirectory.  All of these integration pieces are truly interesting and as I watch these presentations, I notice that one thing is seemlingly glossed over:  “Identity”.   This post is the first in a series of 3 posts that addresses Identity Management from a SharePoint perspective.  In these posts I will give some basic best practices in implementing them in an enterprise.

First, what is Identity Mangement?

So first, terminology.  When it comes to IdM in the SharePoint world, understanding what is what and who is who is key to undertanding.

  • Entity – Each user (or entity) has an identity; that is, everything person, place or thing has something about it that identifies it.  It may be a username, a birthdate, an email address, or whatever.
  • Repository (sometimes referred to as Identity Provider) – Where the relevant information about entities are stored.
  • Claim – An assertion that an entity makes about itself.  For example, an entity may claim that its username is
  • Relying Party – The application, system, or user that requires validation from the Identity Provider that the Claim that has been presented is valid.
  • Authorization – Permission to perform an action.
  • Authentication – Proving an entity is indeed that entity.
  • Federation – Validating another entity’s Identity Provider’s claim about entities for which it is the authoritative repository

For most SharePoint consultants, Identity Management (IdM) consists of mainly two things: Authentication and Authorization.  While IdM does encompass those two concepts (focusing on Identity), it is more than just AuthN and AuthZ.  The operative word being MANAGEMENT.  SharePoint is dependent upon an Identity Provider (IdP) to store its users.  Most SharePoint implementations use Active Directory to store these users. But what happens when the user has  a job change or has a name change or leaves the company or any of a plethora of other identity-affecting events?  SharePoint is unforgiving and unless the administrator loves manual maintenance these events can get tedious very quickly.  What is really needed is a Lifecycle Management plan for Identity.  Sure there are third party tools that address niche situations and some maybe two or three niches (and most are expensive), but they are just a cog in the big machine.

With the advent of SharePoint 2010 comes a new component called “Claims Authentication”.  SharePoint 2010 is Microsoft’s first enterprise application that is natively “Claims Aware”.  (I will go into Claims in a separate post).  This authentication makes an attempt to address the issue of identity which is really a complex issue.  For SharePoint to really put the final nail in the coffin of its competitors, it must address the issue of Identity and allow the consultants to seemlessly integrate it with *any* other enterprise system.  With the BCS (Business Connectivity Services) it comes close; really close.  But there are still concerns with exactly how SharePoint can address the Identity Lifecycle of its users.

In general, when looking at Identity Management solutions, it should be possible to do the following:

  • View, create, modify, and delete users
  • Change passwords
  • Add or delete a user in a security group
  • Approve or reject requests
  • Delegate all permissions

Anyone who has dealt with SharePoint for any length of time knows that the above issues are either very difficult or taken care of by other systems (such as Active Direcotry).  But what if there are more than one password that belongs to a user that resides in another system?  Or even another username?  Things get complicated in a hurry.  Then I have to go to each system to make the appropriate changes (not to mention, make the decision as to which repository of information is authoritative).

Identity Management Hygiene

A good IdM solution (or system that employs good IdM) practices good IdM hygiene.  What does that mean?  For IdM to be reliable, it must be able to obtain an identity from an authoritative source.  Taking that a step further, it must also be able to ensure that the creation of that identity is monitored and audited. That alone probably declares many SharePoint IdM implementations unhygienic.  It should also go without saying that the identity should be locked down in such a fashion that only the true entity has claim on it and prevents any other entity from assuming it or altering it.

As was mentioned earlier, many (if not most) SharePoint consultants concentrate on two aspects of IdM; AuthN (authentication) and AuthZ (authorization).  There are at least two other aspects that should receive the same amount of focus.  These other aspects are Role Based Access Control (RBAC) and Monitoring.  In the next part, I will go into AuthN and AuthZ; delving into Claims Based Authentication and Federation, and then in Part 3 finish with RBAC and Monitoring.


Follow Richard Taylor on Twitter @slckrck

SharePoint and Business Productivity Online Services (BPOS)

A lot of people are asking about Business Productivity Online Services these days.  Microsoft is betting the farm on S+S/SaaS/Cloud Computing.

Software as a Service has long been a buzz word coming out of Redmond as well as the term “Cloud Computing”. SharePoint Online launched a couple of years ago and now boasts one of the most robust SharePoint offerings worldwide.  Some of the biggest names:  Coca-Cola Enterprises, Nokia, and Energizer have taken the plunge into BPOS-D.

D? Yeah, D as in DEDICATED.  The Online Services that you can sign up for a trial on the web is known as STANDARD.  DEDICATED is for the Enterprise customers who are willing to purchase 5000 seats of SharePoint, or Exchange, or OCS, or CRM, etc.

As the reader may or may not already know, I used to work for BPOS at Microsoft.  Good times!  Brilliant co-workers, wicked architectures and insane timelines.  Coca-Cola Enterprises was one that I worked on which required an amazing amount of work to bring to pass.  I learned more than I ever cared to know about how a flagship global company runs network and web services.  Coordinating with data centers in all parts of the world and making sure all the groundwork was in place before SharePoint even got installed was a sort of magnum opus for me.