Mauro Cardarelli

Where Does SharePoint Still Fall Short?

I was interviewed by a collection of SharePoint enthusiasts last week and was asked a number of very interesting questions about the current and next releases of SharePoint.  The one I found most intriguing was “With all the great features in SharePoint 2010, what do you think is the one thing that still falls short?”  I had to think quickly on my feet to not stumble over some lame response and actually liked what I said after I said it (always good!).  Here is my answer…

Security Management.  More specifically, security management by business resources.  With SharePoint 2007, Microsoft delivered on the concept of having all users be consumers and producers of content.  It was very easy to train new SharePoint users on how to upload a document or put web parts on a page.  The challenge, in my opinion, was when these users were asked to manage security for their sites.  Owners?  Members?  Visitors?  Huh?  If you have had to manage a SharePoint environment, you have probably been met with that “help me” email or phone call on how to deal with granting the “right” access to a site.  Let’s face it; the interface for security management is confusing and cumbersome… even for people who use it every day.  What are the consequences?  First, you increase the likelihood of security breaches (i.e. showing content to the wrong audience).  Second, you increase the likelihood of giving users permissions greater than necessary.  Finally, you increase the likelihood of a having a security model that is highly diluted and overly complex.  This is probably why the 3^rd party market for SharePoint administration has been so strong… someone needs to pay attention to what these folks are doing!  But I would argue that this is reactive (versus proactive) management… and things need to be taken one step further.

My thought is that an easier security management interface combined with a simple web part that shows users and access rights (perhaps graphically) would go a long way in truly empowering all users to take SharePoint to the next level without fear of taking it down instead.  It is because of this, and the (minor) changes in SharePoint 2010 security management, that I say that this is the biggest weakness left unfixed.  What do you think?

Another SharePoint Upgrade Success Story

This is one of those “this is what I did and it worked but don’t necessarily try this at home” posts.

Here is the scenario… We had a WSS 2.0 environment that had some data deleted (remember the days of no recycle bin!).  There was no SharePoint backup file and no WSS 2.0 development environment.  Playing the role of MacGyver, I collected what I did have: a SQL Server backup file for the content database, a WSS 3.0 development environment, business users interested in moving to WSS 3.0 (and even more anxious to recover the lost data), deep SharePoint expertise and a positive attitude (at least when this started J).  Oh, and did I mention that the prescan was NOT run before the SQL backup was taken?

This is what I did:

·         Copy the SQL Server BAK file locally to the WSS 3.0 environment (this was a standalone instance so SQL Server was installed on the SharePoint server; obviously if you have a dedicated SQL Server server then put it there)

·         Restore the content database using native SQL Server restore functionality

·         Remember, this content database had not been prescanned (with the Microsoft prescan tool) and I have no environment to perform this.  What to do?  Go to Sites table in the content database and for the sites listed any that have not been prescanned will have a value for ‘BitFlags’ of 0.  Change it to 262144 (the indication that it has been prescanned).  Again, I am not saying this is right; I’m just saying that it worked for me!

·         In SharePoint Central Administration, create a new web application then a new site collection

·         Still in Central Administration, delete the content database associated with the new web application

·         On the SharePoint server, run the stsadm command to attach the restored content database to the url

o    stsadm –o addcontentdb –url <newsiteURL> -databaserver <databaseServer> -databasename <databaseName>

·         The stsadm process will take a while to run if the content database is large

·         When the process is complete, go to the url and validate that you have a recovered (and upgraded) site

Free SharePoint 2010 Book Chapter Available

Well, we did it!  We are in the final edits of our SharePoint 2010 book, Essential 2010 - Overview, Governance, and Planning, and are looking for an early June availability.

As a sneak preview, we are releasing one of the chapters, "Planning for Governance", as a free download.  Click here to visit our book site and download the chapter.

How Many Site Collections Do We Need?

I get asked lots of questions about SharePoint.  One of the harder ones to answer is “how many site collections do we need?”  Why?... because, in my opinion, there is no right answer.  SharePoint implementation is a very personalized experience where you, as a member of the implementation team, make many choices of what functionality to use (or not use) and to set a definition for how it should be used.  Determining the appropriate number of site collections is (or should be) dependent on the choices you make in your information architecture and, in some ways, will ultimately depend on the bias of the information architect(s).

Never one to shy away from a question,  I answer in the following way…

Your decision on site collections will depend on your SharePoint knowledge.  This is split into two main categories, technical and tactical.  Technical knowledge is defined by terminology and concept information that you might find in places like here.  It sets the basis for understanding the limits of functionality within and across site collections.  The second is tactical and is focused on your business users.  It sets the basis for understanding how information workers in your environment best work and adhere to structure (including content organization, navigation, branding, and search).  The cross-section of these two help define your site collection roadmap (I use the term ‘roadmap’ to emphasize the need to consistently evaluate your information architecture and course correct – add/consolidate site collections as an example – as needed).  Remember, there is no “right” answer but your users will most certainly tell you implicitly or explicitly if they think you got it wrong.

When I lead a design session and we talk about site collections I lay out for discussion the items listed below.  In the case of an intranet design, I always start with two site collections (one for corporate content, one for ad hoc collaboration), walk participants through the technical and tactical decision points, and challenge the default design until we get to a comfortable place.  This is a very interesting experience as we often find that one item, navigation for example, will sway the decision making.  Sometimes, we end up with one site collection; often times, it is two or many more… but I NEVER set the number until we get to the appropriate level of detail to make an educated choice.

So, sometimes I answer “how many site collections do we need?” with another question “how many site collections do you think you need… and why?”

·         Quota

·         SharePoint security groups

·         Branding

·         Site columns

·         Navigation

·         Search

·         Backup/Restore

·         Features

·         Distributed site collection administration

·         Security

·         Governance

·         Service Level Agreement (SLA)

SharePoint Admins - Can I get five minutes of your time?

Dear SharePoint Administrator,

I know you are busy.  I know those business folks and corporate executives are driving you crazy with demands for additional SharePoint functionality.  I promise to be brief.  Can I get five minutes of your time this week?

I’d like you to perform the following five tasks.  They shouldn’t take more than a minute each.  The goal here is to give you a pulse on the health of your SharePoint environment.  We’re not trying to fix anything as much as we’re being proactive and looking to not have anything break (forcing those long, drawn out support calls into Microsoft at 2AM).  So, please just go down this checklist then dump this note into a recurring monthly appointment so we can do it every month.  Remember what your mom said about an ounce of prevention…

Thanks!

The Magic SharePoint Elves

1.     Check the date on your last SharePoint backup.  If it is equal to this morning, move on.  If it is last August, set aside some time to get this fixed.

2.     Check the event log on your SharePoint servers.  Red X’s are bad.  If you see none, move on.  If you see a couple, read them and set aside some time to troubleshoot.  If there are lots, make time now to get this fixed.  Remember, when SharePoint gets “sick” it stays “sick”.

3.     Check the disk space on your servers.  SharePoint goes to a very bad place when disk space gets low.  Make sure there is ample space on all the necessary drives.

4.     Check the SharePoint version numbers.  Make sure you are at least to SP2 for SharePoint 2007.  Make sure this version number is consistent across all your front end servers, including development servers.

5.     Randomly test your search security.  Pick two documents from two different places that are secured.  Validate that you can discover them in a keyword search.  Send those keywords to someone who does not have access and confirm the document is not shown.  Pass this test to five business users.