Collaboration

10 SharePoint deployment challenges

Managing a SharePoint deployment entails a number of issues you might not be expecting. Brien Posey runs through some of the most common gotchas.

SharePoint is one of the most flexible server applications available today. But because of its highly dynamic nature, a SharePoint deployment can quickly get out of hand. Here are some of the most common challenges in managing a SharePoint deployment.

Note: This article is also available as a PDF download.

1: Enabling Office integration

SharePoint 2007 is designed to interoperate with Office 2007 to a high degree. If you have users in your organization who are still using older versions of Office, you may find that those legacy versions become a barrier to productivity. So you may want to consider deploying the latest version of Office to all SharePoint users.

2: Preventing site sprawl

One of your primary goals must be to prevent site sprawl. You can use several techniques for this. One of the most effective is to limit the number of people who allowed to create SharePoint sites. Experience has shown that if you allow users to create new SharePoint sites on a whim, some users will create sites they don't even need, just because they can or because they're curious. It's better if site creation is handled by a dedicated group of people within the IT department. I also recommend establishing clear guidelines as to who is allowed to request a new SharePoint site, and under what circumstances.

3: Site lifecycle management

Unlike typical Web sites, many SharePoint sites have a limited useful shelf life. For example, it's common for users to create SharePoint sites that are dedicated to a specific project. When the project is complete, the site is no longer needed. So it's important to have a procedure in place for determining which sites are still in use. When a user requests that a new site be created, you should document the name and contact information of the person making the request, as well as the URL of the resulting site. This allows you to contact site owners on a periodic basis to find out whether the site is still needed.

4: Locating documents

After deploying SharePoint, some organizations eventually begin replacing file servers with SharePoint document libraries. The idea behind this move is that SharePoint contains powerful indexing features that can make documents easier to locate than they would be if they were located on a file server. Although SharePoint has a decent search engine, document libraries can and do become overloaded. It can therefore be tough for users to find the information they need within a large document library.

One way to make it easier for users to locate SharePoint documents is to enforce the use of metadata. SharePoint contains options that allow you to define individual content types and to create custom metadata fields for each one. You can require users to enter relevant metadata for each document they create. This metadata goes a long way toward helping SharePoint return relevant search results.

5: Information overload

Providing good metadata for the documents stored in a document library improves the relevancy of search results, but it will get you only so far. Another thing you can do to improve search results is to implement a policy for document lifecycle management.

While some business documents may need to be retained indefinitely, other types probably have limited usefulness. For example, the odds are good that nobody in your organization cares about a marketing proposal from 10 years ago. By working with the managers in your company, you can find out which documents are really important and come up with a plan for automatically purging other documents after a specific length of time. Doing so reduces resource consumption and helps to de-clutter search results.

6: Governance

The subject of governance seems to come up more often in regard to SharePoint than just about any other application. There is a reason for this. Without proper governance policies, a SharePoint deployment can quickly spiral out of control and evolve into something that doesn't even remotely resemble the organization's original SharePoint vision.

The only way to prevent your SharePoint deployment from getting out of hand is to make some tough decisions up front about how the deployment should be used and who has permission to do what. In other words, you need to decide things such as who has the authority to create a site, what types of data are allowed to be stored within SharePoint libraries, and what types of customizations you want to allow.

7: Disk space management

Disk space management is something of an art form. Most network administrators are used to dealing with file servers that store data on dedicated volumes. SharePoint, on the other hand, stores its data within a SQL database. While you can use quota management to ensure that users don't consume an excessive amount of disk space, it is important to realize that multiple lists or libraries can be linked to a common database. Therefore, you must design your quota structure to take into account possible growth of other lists or libraries that may exist.

8: Web part management

SharePoint sites are built around the use of Web parts. This approach make site creation easier, but it also means that any changes to Web parts result in changes to every site that uses them. You'll want to take measures to prevent Web part customizations from being made in a haphazard manner. A modification that enhances a Web part's functionality on one site may wreck havoc on other sites that are using that Web part.

9: Service level agreements

Many organizations discover that it doesn't take long for a SharePoint deployment to grow from being something of a novelty to becoming a mission-critical application. As with other mission-critical applications, administrators are often pressured into accepting service level agreements for SharePoint deployments.

My recommendation has always been to use the quest for service level agreements as a bargaining chip. For example, you could explain to the managers in your company that for you to be able to deliver the level of service they are requiring, you need additional server hardware or other IT resources.

10: Disaster recovery planning

I have seen a few real-world situations in which administrators verified that their backup software supported SharePoint but never really looked at what was required to perform a restoration. Unless you're going to be performing a total restoration, most backup applications require SharePoint data to be restored to a recovery farm.

A recovery farm is a separate, dedicated SharePoint farm. Although a recovery farm does not require the same hardware resources as your production SharePoint servers, it does have to be configured with the same features, templates, patches, and software versions as your production farm. That being the case, a recovery farm isn't really something you can just throw together at the last minute when you have to perform a restoration. You will need to have it in place in advance.

About

Brien Posey is a seven-time Microsoft MVP. He has written thousands of articles and written or contributed to dozens of books on a variety of IT subjects.

25 comments
agodfrey
agodfrey

It's the nature of intranet sites to become larger and larger and unless they are culled regularly end users start getting older 'mis-information'. One solution is EScreenz that points end users to specific (hopefully newer) targets within SharePoint or any intranet site for that matter.

elizabeth.trent
elizabeth.trent

A lot of good points have been brought out in this article. In my view - SharePoint is a lot more than just another pretty file management system (not that pretty by default if you ask me). Being able to create and deploy custom workflows using windows workflow foundation with as many branches and conditions as you like; creating websites-groups-permissions-workflows-document libraries automatically at runtime; deploying custom C# web controls as web parts - these things can have a lot of power. There is already a sound architecture in place that you can extend without re-inventing the wheel. In a lot of cases, 80% of what users want to do can be done with SharePoint "out of the box" (but that's pretty boring...) so users can do quite a lot (including basic workflows) on their own without necessarily having a developer at their disposal. One of the big challenges with deploying SharePoint for me is software development lifecycle and configuration management. Since SharePoint stores changes to pages in the database, that makes it a real challenge when it comes to versioning control of the site configuration itself. How do you keep your development environment in sync with your staging/testing environments and still be in sync with production? Migration can be a real nightmare. Just because you made backups of your development or test site doesn't mean that you can then restore them to an installation on another server. That would take all the fun out of it. The command line tools for backing up a website as such have limitations - size constraints being among them. Yet - because the page and list changes are stored in the database, you can't just over-write what you have in production with what you just developed. I guess you could but you'd have to 1) know which content database(s) your site is using 2) back them up before deployment 3) restore after deployment 4) pray a lot (and hope there aren't any major list structure changes that are going to blow up your stored data and break work flows). If the only thing you are changing are your deployed custom webparts - that isn't quite as ugly...it's a matter of deploying your dlls, publishing the dlls to the global assembly cache, making changes to your config files, etc. Security is another thing to consider. By default - the basic SharePoint groups/role definitions are 'read', 'contribute', and 'full control'. The problem with that though is that all of these definitions allow everyone to see everything -- so if you want to present content based on the user's role - you have to jump through a few flaming hoops. The learning curve has been pretty steep for me - I've had to learn everything I've learned on my own...and I still consider myself to be fairly new to this type of development. Sometimes I wonder which is less painful...SharePoint - or whacking myself on the head repeatedly with a brick. I just wonder if anyone else has experience with these things and has recommendations for configuration control and migration for incremental releases.

tbostwick
tbostwick

IMHO - SharePoint was developed to promote the need for paid support by M$ professionals only. There is extremely limited support for this product outside of M$ and for the incredible amount of mgmt. and maintenance, not to mention the renaissance programming skills required as well as a DBA - this is the "beast" of Microsoft. I'm in favor of the KISS system when it comes to sharing - which is to say, that sometimes you have to live with differing systems that DO and CAN integrate - which work just fine, don't require 5 extra people on staff, and are relatively headache free. Thumbs down to SharePoint - deploying it any fashion no matter the version. You simply don't "have to use it!" T Bostwick SystemsAdmin/Analyst/Development

IT
IT

GUI: It's a similar approach to the rest of windows...if you don't like it, you'll need to go elsewhere. Having said that, it's one of the most flexible and effective interfaces ever created by MS. I think there are 3 points you should consider - First, any document management system has some overhead, if you don?t want those features, turn off versioning & checkin/checkout and any workstreams associated with the document library. Second, it?s easy enough for anyone to configure, with a little time investment, try one of the 10-minute books (MS SharePoint 20xx in 10 minutes) to get very specific directions on changing the configuration. Last, you can turn to SharePoint Designer, which has virtually unlimited ability to tweak & configure sites?which is one of the reasons most IT shops limit it?s use. Site Sprawl (#2): duh. But site creation is one of the most powerful and useful features for collaboration, such as workspace sites. We?ve been using Meeting workspace sites for sometime, and they are enormously effective ways to improve meetings. The downside is that they create a subsite?right from Outlook when you create a meeting appointment. Surely you?re not suggesting IT get involved in creating these? Or are you just talking about main sites?

spawnywhippet
spawnywhippet

Am I alone in detesting the user interface of Sharepoint? Over the last 6 years, I've worked on many projects at 3 different multinational corps and all of them started by using Sharepoint as the project document repository, but in every single instance, people ended up just emailing documents around as it was a whole lot easier and quicker to work with Outlook than Sharepoint. Does anyone have a well configured Sharepoint that normal users used actively and enjoyed working with?

Brock_A
Brock_A

What other viable alternative exists? ie. What else is there on the market that can provide the same level of functionality?

GerryR1
GerryR1

Two more failed experiments in Microsoft's attempt to dominate the world of software. Fortunately Google is too big for them to buy.

CharlieSpencer
CharlieSpencer

Well, not fighting it, since I can't find any opponents. My users prefer to dump everything in shared folders, creating sub folders as needed. SharePoint has received some favorable acceptance in our other facility, the one that's more project oriented than this one. Here there has been as close to no interest as possible. vorpahl mentioned the importance of the roll-out, but no one here seems to have a use for it. Combine that with no easy way to migrate the massive amount of information in our old document management system (DocsOpen) over to SP, and the reluctance of my users to having to search two storage systems. Addressing k.stafferton's point, I'm not seeing the advantages of using Office 07. Maybe I'm not integrating the apps with SP as effectively as possible. I can't figure out how to access files stored in SP from an Office app. Also, I recall a way to create a 'Network Place', but I remember it as being a lot harder than just mapping a network drive in a login script.

kevin.stafferton
kevin.stafferton

Isn't that why you should deploy Office 2007? You are then able to save and share directly from SharePoint document libraries without using the web front end. Alternatively, you can also map the document libraries so they function like a network shared folders.

gechurch
gechurch

He already answered that right there in his post... you keep it simple by having multiple different products, then spend your time programming kludges to get the differing programs to interoperate. Then, of course, you re-program when the next version of any of your programs is released. Writing code specific to multiple programs to get them to talk is so much easier than having the apparant 5 IT staff you need to use SharePoint's edit-what-you-see interface.

ITManagement
ITManagement

We started implementing SP2007 back in 2007 as a simple replacement for the SPS2003 Intranet site everyone hated. It took about two years for users to start seeing the value of the new SharePoint system. Over time, we developed various features and deployed numerous web applications to address corporate issues discovered during process analysis across the enterprise. We are slowly migrating appropriate documentation and processes to SharePoint in a multi-year phased approach that doesn't force the technology on everyone. Our SharePoint champions have really taken hold of the technology and now manage their own department sites. One department went entirely paperless using workflows and links to documents in their site. Consequently, they are saving over $75,000/year in gained productivity and reduced expenses. We are seeing a steady climb in acceptance now and have numerous projects to extend the functionality. People simply need to see the value in action, something that is provided by leaders with vision. None of this would have happened if the technology couldn't support the effort or if the right people weren't on the job to support and implement the technology in appropriate ways. It is a team effort that takes patience, planning, and pro-actively applying the technology to solve business problems and addressing user needs. With 2010, we anticipate another increase in momentum from other segments of our business that have seen limited functionality in 2007 for their tasks.

gechurch
gechurch

On what are you basing the claim that SharePoint is a failed product? It's definitely not a product for eveyone, but it's great at what it does. Overwhelming I've found posts by people that use the product to be positive. The only negatives I tend to hear are related to poor implementations, trying to bend it to do things it wasn't intended to do, or where users were not involved. I'm far from convinced it was an attempt to "dominate the world of software" either. Indications are that Microsoft saw this as a niche little product... something nice to throw in with Server for free. I think they were surprised at how popular it became. It is now a billion dollar product for MS, and is set to be the fastest growing Microsoft product to $2 billion.

CharlieSpencer
CharlieSpencer

Apparently they're selling enough of it to continue development, sales, support, etc.

CharlieSpencer
CharlieSpencer

Something else to learn about a product I'm still trying to figure out. Beautiful, just beautiful. What does this afterthought bring to the party? Some additional functionality that MS would have included in the first place if they weren't in a rush to get to market? Sorry, my cynicism is running high this afternoon, especially where this product is concerned.

tbostwick
tbostwick

My main question would be: Why go with SharePoint then? or are you stuc in having to support the product. Use folder shares, encrpyption software and VPN's where needed for remote users. Limit access and viewability by the locks at the AD level and start with that. Office2007 doesn't offer anything new for SharePoint ease-of-use. I'd also consider some of the "secure" online storage access vendors, of which there are hundreds if not thousands.

GSG
GSG

Well, relatively long, anyway. We use it in IT for projects. When a project starts, we create a site, then as the system is implemented, the site is transitioned over to a support site. We keepp all of the documents from the contract negotiations and the project implementation, including all of the manuals, then we keep the procedures related to that system there. When the product is replaced, the website is archived. We also use the workflow capabilities that are a more recent addition. For example, we have a new doctor on staff, and there are a lot of people who have to know when the credentials are verified and what date the Doc is starting. There's a checklist, and depending on what step is completed, certain notices go out to certain people. That's helped the process. In addition, the Policies and Procedures are all online. The only problem is enforcing the use of Metadata. Our Sharepoint admin has been trying to get people to use that intelligently for a while now.

pjboyles
pjboyles

You must install one of the versions of Office 2007 that support SharePoint integration to have a seemless SharePoint experience. - ProPlus, Ultimate, Enterprise

vorpahl
vorpahl

That's exactly why we went with SharePoint. I took various manager level people, who were scrolling pages and pages of outlook screens as some kind of "file management system", to a single SharePoint Document library. It was a no brainer and is used readily. I agree, most companies don't have the process-minded people in place to make their rollouts a success. They think "just throw it in SharePoint and it will work".

CharlieSpencer
CharlieSpencer

I played with both FP and DW for a simple personal site. They were far more tool than I needed, like having a full wood shop when all I needed was to drive a couple of nails. I never dove very deep into either one.

gechurch
gechurch

Yeah, I never liked FrontPage. I can't say I ever spent long enough with it to have given it a fair go, but it just didn't feel right to me. I've always used Dreamweaver, and from the limited time I've spent with SharePoint Designer, it seems to be pretty similar.

CharlieSpencer
CharlieSpencer

It would have to be. I tried FrontPage a couple of times and could never get anywhere.

gechurch
gechurch

SharePoint Designer is Microsoft's replacement for FrontPage. It's a far better product though. And you don't have to learn it - it's only needed if you want to make customisations that can't be done using the web interface or CSS. I recommend avoiding these if possible anyway.

GSG
GSG

It's a useful tool for us. We have people who don't have, and don't need to have, calendars, outlook, network shares, etc... This is one place to aggregate information such as policies and procedures, announcements, training materials, team collaboration sites, the previously mentioned workflows, etc.. Will every business like it or use it? Absolutely not, but it works for us, and solved many more problems than it creates.

CharlieSpencer
CharlieSpencer

It wasn't my call. Its successful implementation at our other site has my superiors wondering why the users at my site aren't don't get it. By extension, there are questions about my ability to recognize its value and 'sell' it to them. (Hell, I have questions about how to best use it. I've never seen a similar system and don't recognize when it would be the appropriate tool.) Our DocsOpen installation is over a decade old, unsupported, and must be replaced. SharePoint is the logical candidate, but my users won't consider it until the existing data in DocsOpen is migrated. I've seen no actions on this front, only an agreement that it needs to be done. Such an operation is over my head. There's also the question of SP's capabilities being oversold to the users. I was excluded from the presentations that were held over a year before roll-out. Users have told me that the final implementation has fallen well short of the promises and potential present in those meetings. It leaves an understandable bad taste in their mouths. Part of the implementation is an emphasis on content management by the users. Frankly, they don't have the skills, and I wouldn't expect them to; content management isn't their job. This is accompanied by the usual lack of training. It was rolled out with a 'Here it is! Have at it!" approach. This may have worked at the other site, with a much higher percentage of engineers, project managers, propeller heads, and other types who enjoy playing with new technologies, but not here.