Let me start off by saying that in this short posting, I don’t intend to provide or discuss any solutions, that specifically address de-duplication of content in SharePoint. But rather explore the idea, that duplication of content is often mistaken for a problem its not, and that while de-duplication may seem like the most logical solution; it may really cause more problems then it solves.
I believe that when the topic of duplicate content comes up it generally revolves around content discovery, primarily the impact that duplicate content has on search results. While duplicate content is quickly pegged as the culprit, it’s really more of a discoverability issue around authorative content. Removing duplicate content may not really be the solution, but perhaps effectively surfacing authorative content by reconfiguring search result page(s), fine tuning your search configuration, and doing a better job leveraging refiners and scopes.
As a user who sometimes copies documents and presentation from other areas into my own collaboration or personal sites, I wouldn’t be in favor of a solution that automatically removes my copies. I believe that in trying to remove duplicate content, you’ll quickly find many such users, and you may ultimately find yourself trying to change too much about how your users get work done.
Of course, discoverability may not be the issue you are trying to solve with de-duplication, in which case it may ultimately have to do with storage. If so, it may point to a bigger issue around information architecture, lifecycle management, and content expiration… But I’ll leave those topics for another time in the interest of keeping this posting short.
The Houston SharePoint User Group (HSPUG) is proud to present the first SharePoint Saturday event for the greater Houston area on May 1, 2010.
This event will be from 8:00 am – 6:00 pm at Norris Conference Center, 803 Town & Country Lane, Houston, TX 77024. 713-590-0950. We will provide a continental breakfast, break refreshments and hot lunch. Parking is free in the parking garage (adjacent to Norris and Studio Movie Grill) in the 3rd level and above. Enter Norris on the third level from the south end of the parking garage.
About SharePoint Saturday: Whether you are a IT professional, professional, business owner, manager or enthusiast, SharePoint Saturday is an educational, informative & lively day filled with sessions from respected SharePoint professionals & MVPs, covering a wide variety of SharePoint-orientated topics. SharePoint Saturday is FREE, open to the public and is your local chance to immerse yourself in SharePoint!
Seats are limited so, register today! http://www.sharepointsaturday.org/houston/default.aspx
I’ve posted the PowerPoint deck of the presentation Apollo and I gave yesterday at the Houston Tech Fest: click here to download a copy.
It was a great event and I look forward to participating again next year. Thanks to all who attended our presentation.
This is a topic that keeps on surfacing, and I don’t expect it to go away any time soon: When should we (if at all) use folder structures in SharePoint Libraries? As much as I hate to admit it, there is no simple answer. But personally, I don’t often see many compelling reasons to use folders in SharePoint.
Folders are essentially just another solution, or tool, to address a specific need; organizing files, or data, in some sort of logical structure, so that users can easily and/or quickly find the files or information that they are looking for. But using folders for this purpose with SharePoint would be much like using a modem to connect to the internet, while you had an Ethernet or WIFI connection readily available. Or storing your contacts on a rolodex, while having an electric organizer, PDA, or cell phone.
But if folders are so antiquated and inefficient, why does SharePoint gives us the option to use them? I can think of a couple of reasons, and have ran into some of them personally. I’ll elaborate on these a bit later, first I’d like to go over some of their limitations; some examples of why we should not use folders.
For starters folders are hierarchical in nature, and force us into a single structure per implementation; this alone has many implications. Consider the following scenario:
You’ve been given the task of organizing and maintaining manuals for specific systems within your organization (phone, fax, printers, copiers, voicemail, video conferencing, etc.) . Your organization is composed of several regions, each with specific divisions and offices in different locations. Not all offices share the same products or services (some do.) All of the offices share a common network. You’ve been given three simple requirements:
- Group A needs to browse the files by location (ex. Region > Division > Office)
- Group B needs to browse the files by product type (ex. Printers, Fax Machines, Copiers)
- Group C needs to browse the files by vendor (ex. HP, Kodak, Lanier, Polycom)
You’d be in quite a predicament…. You could create a folder structure such as the following:
- North America
- South America
- Division 1
- Division 2
- Office 1
- Office 2
- Fax Machines
Which would satisfy the requirement of group A. But groups B and C would not likely be satisfied, and to make matters worse, you’d likely have to maintain duplicates of the same manuals (which you could possibly mitigate by utilizing shortcuts.) But all in all not a very elegant solution, some might say it is quite the opposite.
Alternatively you could create a folder structure like this:
- Fax Machines
This would likely meet the requirements of group B and maybe even group C. It would also do away with duplicates. But what about group A.
There are many variations to this scenario, and the requirements may not always be given up front. A specific folder structure may work well for a period of time, and suddenly change; management may decide they want to view files in a different way.
But why would you try to use folders in the first place, when you could rely on views? Views would meet any one and all of these requirements. The information captured in the folder names should be stored as metadata with the specific files. You could then create a view that groups by; Region, Division, and Office; another that groups by Product Type; and yet another that groups by Vendor. Given the right AD groups and putting a little extra work towards setting up audiences, and you could create a page that automatically shows a different web part with the correct view for each group.
Some other reasons not to use folders:
- If you are basing your folder structure on your organizational hierarchy; keep in mind that these hierarchies can and often do change. Something much easier to manage using site columns, and views.
- If you do have to change the value of a Region, Division, or Office; which you’ve happened to use in your folder structure. Any links, bookmarks, or shortcuts to these files would probably break as the folder names form part of the Url.
- Folders increase the length of the Urls, which can cause errors after reaching a certain limit.
- Get your users thinking outside the box. Giving your users a couple of views that have properly named helps them think of other ways to look at the data. Even when your views closely resemble a folder structure. For instance giving them a view named “Products by Region”, lets them know that they could just as easily have a “Products by Office”, “Products by Type”, or “Products by Vendor”. And that they themselves could create similar views for the data they are responsible for in SharePoint.
So why does SharePoint offer folders in the first place, if you can just as easily and more efficiently organize your data with views? The following are a few scenarios where I’ve seen folders come in handy:
- Folders make it easier to apply different set of permissions to logical groups of files within a single library. However, keep in mind that this can and often should be accomplished by using different libraries. If you are worried about consistency across the libraries; consider using content types, or a library template.
- Copying files from libraries in bulk (using explorer view) and keeping some sort of logical structure. In my experience I don’t often see many scenarios that require users to copy files in bulk. While certain users may have the need to do this every once in a while, consider the repercussions, and remember that you should be configuring your library for the norm and not the exception. If copying or moving files in bulk happens to be the norm if your scenario; consider creating a new sub site for the group as a whole and splitting the files up into multiple libraries within that sub site.
This is a fairly common and non-descriptive error that continues to surface more and more as the SharePoint developer community continues to grow. Surprisingly, I’ve found very little information in the web regarding what I believe to the most common cause and solution (hence this blog post).
Many things can trigger this error, and as you might expect by the description the error is security/permissions related. I’ve seen it most often, when browsing the Site Features and Site Collection Feature pages… but it has been known to take down a whole site; although mostly (and luckily) in dev environments.
So why do I keep referring back to development? And more importantly, what is this “most common” cause/solution? Its mostly tied to “drag and drop”; when you drag and drop files, permissions usually go with them (albeit there are a few exceptions.) With development rarely taking place directly in the 12 hive features, or layouts folder; its shouldn’t be surprising to see developers (and administrators alike) deploying and often testing changes to features by dragging and dropping files from their Desktop, My Documents, or project folders. Naturally this approach doesn’t follow best practices, but I wont deny having made the mistake while testing a quick change to a feature or elements xml file in a development environment. All updates to production environments should be done via WSPs.
So how do you solve the problem? Finding the culprit shouldn’t be too difficult, think of any items that have been recently deployed/updated. Cant think of any, search for any recently updated files of folders. If you do think of or find any; check the permissions and make any required modifications; also consider redeploying them via a WSP.
This week, I gave a presentation on “Editor Parts” at Houston’s SharePoint User Group event. It included a live demo on how to build an Editor Part that displays a dropdown of all of the Lists for the site where the corresponding web part is being deployed. I’m including links to download the presentation and source code below:
Let me start by saying that while executing code via RunWithElevatedPrivileges may help you overcome certain “access denied” exceptions in your code, using it should be the exception not the norm. This is not meant to be a “how to” posting on RunWithElevatedPrivileges, there are plenty of articles out there that already cover just that. Instead I’d like to focus on a subject that I consider to be just as important; when is the right (and wrong) time to use this command.
I recently wrote an article for the MSDN on “Securing Application Pages for Windows SharePoint Services 3.0”. In it, I provided several code samples on how to do just what its title implies; some of which included calls to RunWithElevatedPrivileges. A respected colleague was quick to point out a concern; that some of the information contained in the article (specifically references to RunWithElevatedPrivileges) might result in certain individuals using the command without giving it sufficient thought.
The very reason I wrote the article, stems from how often I’ve seen this command used, and the security risks it presents. I’d hate for the article to be seen as a case or excuse for calling this command, when in large part is the very thing it tries to protect developers from.
SharePoint provides a very extensive and well thought out API, at least from a security standpoint . It uses impersonation, meaning that the code you write will execute under the context of the user viewing the page where your code resides. If you write a web part or application page that reads or writes information from a SharePoint List, Library, or Site that does not grant the user such rights; your web part or application page will throw an error… as it should. Your first instinct should not be to rewrite your code so that this logic executes via the RunWithElevatedPrivileges command. Doing so might be considered a hack.
That’s not to say using RunWithElevatedPrivileges is a “hack” every time, there are certain unique cases where you don’t have much of a choice. But first consider checking if the user has the necessary permissions via the DoesUserHavePermission method of either the SPSite, SPWeb, SPList, or even SPListItem your accessing with your code, and avoid doing anything further on that item if the method returns false for the required permission level. Alternatively (although often cause for debate) consider handling the access denied exception. Ultimately, don’t hurry too much writing your code, the quickest way is not always the best way.
Happy Coding. Oh.. and thanks for the pointer Matt.
An article I recently wrote has just been published on MSDN. It covers the basic principles of securing application pages, and why they are often at risk; as well as providing code samples on how to properly secure your application pages, including:
- How and when to validate page requests
- How to verify Base Permissions
- How to verify Role Definitions
- How to verify Group Memberships
Last week, I presented this topic at the Houston SharePoint Users Group. I really enjoyed giving the presentation, only slightly disappointed that I wasn’t able to attend the technical track which was occurring simultaneously…. I’ll get over it though
The presentation itself contains a lot of useful information. Thanks to all who provided feedback, and my colleagues at Catapult who helped put it together.
I have uploaded the presentation here.
I am now offering this same course with Field Advantage Training, check them out at http://www.fieldadvantagetraining.com/ for the latest on upcoming sessions, pricing, and new courses. The name of the course has been changed to SPDC101 – Core SharePoint 2007 Development.
The last SharePoint Developer – Weekend Crash Course was a complete success. I’d like to extend a big thanks to all of you who participated in helping me put it together, and to all of the attendees for your positive feedback and references; you all rock!
Based on the number of inquiries I’ve had from readers and references who’ve shown interest in taking the course, I’ve decided to repeat the course here in Houston on September 12th and 13th of 2009.
This course is designed to cover the most common and critical SharePoint development topics I’ve come to expect from SharePoint implementations, based on several years of experience across multiple industry sectors. The course is meant for experienced .NET developers with entry to mid level SharePoint development experience.
The class will consists of a series of discussions and instructor led hands-on labs. The full agenda has been listed below. Attendees will need to bring their own laptops, for which I have posted minimum requirements (see hardware and software requirements below.)
Attendees will receive:
- An external USB 2.0 Hard Drive with 80 GB or more of storage
- A Virtual PC image running trial versions of Windows 2003, SharePoint 2007, and Visual Studio (included in the hard drive.)
Core Concepts (8:30 am – 9:45 am)
15 minute break
Extending the Out of the Box Experience (10:00 am – 12:00 pm)
1 hour lunch break
Custom Web Part Development (1:30 pm – 2:45 pm)
15 minute break
Custom Site Definitions (3:00 pm – 5:00)
Feature Development and Feature Stapling (8:30 am – 9:45 am)
15 minute break
Content Types and Event Handlers (10:00 am – 12:00 pm)
1 hour lunch break
Custom Application Pages and Extending the Menu System with Action Items (1:30 pm – 2:45 pm) Instructor led Hands On Lab
15 minute break
SharePoint Solution Packaging and Deployment (3:00 pm – 5:00pm)
Hardware and Software Requirements:
- Laptop computer with a processor speed of at least 2.5 GHz with Hyper Threading or Dual Core Technology
- RAM capacity of 2 GB minimum (3-4 GB recommended)
Must be able to allocate a minimum 1 GB of RAM to the Virtual OS
- Operating System: Windows XP Professional or Windows Vista
- Additional Software: Adobe Acrobat, Microsoft XPS Viewer
- This course is not meant to provide an introduction to SharePoint or the .NET framework. Attendees are expected to have experience with the SharePoint platform as well as .NET development with Visual Studio.
- Registration is limited.
550 US dollars per person
(group discount rates available)
Catapult Systems, Houston
10370 Richmond Ave. Suite 1250, Houston, TX 77042
1. Click here to download the registration form
2. Complete the registration form and fax toll free to (877) 819-0945
Call 832-472-3648 or e-mail email@example.com for more information
Please refer to http://www.rafelo.com/sharepointtraining for the latest information.
Here’s what some of the attendees had to say about the last session:
“Rafael’s Developer Crash Course was excellent! It really was a crash course covering a lot of concepts in a short period of time. But every item covered was a practical, real-world solution that I can use as a .Net Developer to help our Administrators more easily manage our SharePoint farm. And he made it easy….” – Barry Thomas, Panhandle Energy
“I was excited about the class before it started and was not disappointed when it was over. You delivered everything I expected and more.” – Don McKenzie
“Rafael provided clear, step-by-step instruction as to the ins and outs of content management in Microsoft Office SharePoint Server 2007. I would recommend this class as an effective, inexpensive way to hone your SharePoint development skills.” – Troy Lanphier, Catapult Systems
“Rafael’s training series gets two thumbs up. The precision of this course was a balance of a technical and functional workshop to illustrate real life scenarios of business solutions utilized in our day to day corporate operations.” ”I recommend this course to developers and functional people who wish to add value to their organization and grow within the SharePoint community. Rafael, best wishes and continued success on all of your SharePoint endeavors.” – Reece Collins, Inseptions
“Prior to attending the class, I was convinced that I would need a great deal of C# training before I could begin to develop in SharePoint. Rafael’s class provided insight that allowed me to build and deploy solutions for my clients’ SharePoint environments.” – Marlene Lanphier, GUIO