Advancing Productivity and Operational Efficiency through Cloud Services and Apps



Back to Basics: Using Folder Structures in SharePoint Libraries

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:

  1. Group A needs to browse the files by location (ex. Region > Division > Office)
  2. Group B needs to browse the files by product type (ex. Printers, Fax Machines, Copiers)
  3. 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:

  • Manuals
    • North America
    • South America
    • Asia
      • Division 1
      • Division 2
        • Office 1
        • Office 2
          • Phones
          • Fax Machines
          • Printers
          • Copiers

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:

  • Manuals
    • Phones
    • Fax Machines
    • Printers
    • Copiers
      • HP
      • Kodak
      • Lanier

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:

  1. 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.
  2. 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.
  3. Folders increase the length of the Urls, which can cause errors after reaching a certain limit.
  4. 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:

  1. 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.
  2. 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.
digg_url = “”;digg_title = “Back to Basics: Using Folder Structures in SharePoint Libraries”;digg_bgcolor = “#FFFFFF”;digg_skin = “compact”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;

RunWithElevatedPrivileges – Exception, Not the Norm

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.

Project Planning for SharePoint Implementations

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

digg_url = “”;digg_title = “Project Planning for SharePoint Implementations”;digg_bgcolor = “#FFFFFF”;digg_skin = “compact”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;

Submitting Items to Lists from Custom Application Pages

This posting is in response to a comment I had on a previous posting; “Using the InputFormSection and InputFormControl to build Custom Application Pages that look like OOTB Pages”. One of the readers posted a comment asking how to go about using the submit button to post to a list. Needless to say, I didn’t feel that answering his question by replying to his comment would be the best response. So I’ve decided to post my response here, where its a little bit easier to elaborate on the subject.

Application pages can in fact be used to create list items, but there are a number of things to consider. The first and probably most important thing, is that application pages can be accessed from any site in your SharePoint farm. If the list the form is meant to write to is accessible globally this may not be much of a problem, but I’d have to question how that list was created and where it is stored. Application pages are part of what I consider to be a fairly modular development framework in SharePoint, and the scenario mentioned doesn’t sound very modular at all; a page that is deployed or accessible from every site, but the list it writes to is only deployed to one. What if the site containing the list is deleted? Or certain fields changed? The site administrator would likely be able to do either, but he/she wouldn’t be able to update the Application Page, which would likely break.

So how do I recommend using Application Pages to write to lists? There are many ways, most (if not all) of which would involve Features. The following is a sample approach:

1. Develop a site or site collection Feature that creates a list. Since we will be writing to this list from a Custom Application Page, I recommend that the list be hidden. This recommendation stems from the fact that we don’t want anybody accidentally deleting or modifying the list, which may impact the Application Page. Of course this would probably mean creating another page to view and/or edit list items; this could be a Content Page or Application Page.

2. Develop the Application Page that writes to the list created by the feature, including logic in it that checks if the feature is activated. If the logic determines that the feature is not activated, the page should display a message stating that the feature needs to be activated for the page to work.

3. Use Custom Actions and Custom Action Groups to create a link to the Application Page(s) from the “Site Settings”, or “Site Actions” menu.

I don’t mean to imply that an Application Page shouldn’t be used to save items to a single globally accessible list. But it requires even more consideration and planning than the scenario mentioned above. Actually, I’ve had to develop such pages; in one example the list resides in Central Administration and is created as part of a Feature scoped at the Farm level.

In another scenario, the list may not be hidden, or even created by the feature. The list may be manually created (to capture very specific criteria) by a site or farm administrator, in which case another Application Page may be used to capture the location of the list, and save it in the property bag of the site or site collection. The Application Page that writes to the list, fist looks at the property bag to determine its location, if the property has not been set, the page simply returns a friendly error.

Like the above mentioned scenarios, I’m sure there are hundreds more. The point is all of them require some thought. Unless strictly used to display information that you know is always available, an Application Page is rarely a solution as a whole. Take time to carefully plan and design your Application Pages, examine your solution from multiple angles making sure it doesn’t easily break. Remember, if you fail to plan you are planning to fail.

digg_url = “”;digg_title = “Submitting Items to Lists from Custom Application Pages”;digg_bgcolor = “#FFFFFF”;digg_skin = “compact”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;

SharePoint – Architecting for Success

Last week, I gave a presentation on “Architecting for Success” at the SharePoint Technology Conference in San Francisco. It was a subset of full day workshop titled “Success with SharePoint – From Start to Finish”. For those of you interested, I’m making the presentation available for download here. (

Integrating Project Server with your SharePoint Farm

This topic has been coming up quite a bit for me recently, specifically the integration of Project Server with an existing SharePoint 2007 farm. I happen to have a strong opinion about it; whenever possible keep Project Server in a separate farm from that of your Portal, Intranet, and Extranet sites. Clearly, I cant make this recommendation for every scenario… but I do believe it’ll apply the vast majority of the time. If for whatever reason you can’t have more than one farm (it may very well be out of your hands), I will include some tips or best practices to help keep your farm in harmony.

Why separate farms? While Project Server relies heavily on SharePoint for the vast majority of its features (quite the understatement); Project Server environments are generally used very different from how Portals, Intranets, Extranets, and ECM environments are used. Having them on different environments allows for easier maintenance of one without impacting the other; this is particularly important with upgrades.

So how does integrating Project Server with the farm hosting your other environments affect it? For starters, if you are planning on upgrading either your standard SharePoint or Project Server sites; you cant really upgrade either without upgrading the farm… and since all are sharing the same farm, your not really left with much of a choice, unless you split them out while performing the upgrade… and now you’ll have 2 projects on your hand.

Also keep in mind that the user base will be completely different, as will be the stakeholders, and any project sponsors; as such, any SharePoint related initiatives of one group will have to be coordinated with the others. You’ll also likely have separate SLAs and governance for each environment.

If you only have one farm available, there are a couple of things you can do to help:

1. Keep the Project Server (PWA and Workspace Sites) in their own separate web applications. This setup will lend itself for an easier migration to a separate farm if an upgrade or separation is ever required, and allows for better segregation of both administrative and maintenance tasks.

2. Having a dedicated WFE (Web Front End) for your Project Server sites will help improve performance.

Using the InputFormSection and InputFormControl to build Custom Application Pages that look like OOTB Pages.

I’ve seen this topic covered indirectly and even unintentionally  in a number of posts, some of my favorite references include: “Using the SPPropertyBag with Custom Admin Pages in SharePoint” where Steve Graegert dedicates a section of the posting to talk about the “Page Structure”. Another is “Creating Custom Timer Jobs in Windows SharePoint Services 3.0” by Andrew Connell, in this one, the subject is not covered directly but the code provides a great example of how the controls can be used.

In this posting I’ll try to cover the subject directly using a basic application page and creating a very simple form.

We’ll start out with the application page; copy the following code and save it as an ASPX page in the SharePoint Layouts folder (usaually c:\program files\common files\microsoft shared\web server extensions\12\template\layouts\)

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=, Culture=neutral,
PublicKeyToken=71e9bce111e9429c” %>

    Sample Application Page

    Sample Application Page

    This is a page provides an example of how to use the InputFormSection
    and InputFormControl control templates to create an application page
    that looks like the SharePoint OOTB Application Pages.


When accessing the page from the browser (i.e. http://siteurl/_layouts/pagename.aspx) should yield the following result:

Add a “register” directive for each of the controls in the page as follows:

<%@ Register TagPrefix="wssuc" TagName="ButtonSection"
src=”~/_controltemplates/ButtonSection.ascx” %>

Next we’ll add a table to the “PlaceHolderMain” content place holder as follows. This table will be used to house our controls:

    This is a page provides an example of how to use the InputFormSection
    and InputFormControl control templates to create an application page
    that looks like the SharePoint OOTB Application Pages.








Insert the InputFormSection control to the table as follows:

    This is a page provides an example of how to use the InputFormSection
    and InputFormControl control templates to create an application page
    that looks like the SharePoint OOTB Application Pages.






        <wssuc:InputFormSection runat="server"
            Title=”Sample Form Section”
            Description=”This is a sample form section” >



This change should yield the following result:


Next we will add the “Template_InputFormControls” element, which will contain our actual form controls. This will be displayed in the right section of the form (the light blue section.) We will also add the “ButtonSection” control which we’ll use to house the buttons for our form. See the full code sample below:

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=,
Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>

<%@ Register TagPrefix="wssuc" TagName="ButtonSection"
src=”~/_controltemplates/ButtonSection.ascx” %>

    Sample Application Page

    Sample Application Page

    This is a page provides an example of how to use the InputFormSection
    and InputFormControl control templates to create an application page
    that looks like the SharePoint OOTB Application Pages.






        <wssuc:InputFormSection runat="server"
            Title=”Sample Form Section”
            Description=”This is a sample form section” >

        <wssuc:ButtonSection runat="server" TopButtons="true"
            BottomSpacing=”5″ ShowSectionLine=”false”>
                <asp:Button UseSubmitBehavior="false" runat="server"
                    class=”ms-ButtonHeightWidth” Text=”OK”
                    id=”BtnSubmitBottom” Enabled=”true”/>


The result should look as follows:



SharePoint Solution Development; Define and Design Guidelines

In my previous posting, “SharePoint Solution Development, Planning for Success“, I wrote about how the lack of a clear definition and design will almost undoubtedly impact the success of a SharePoint solution development effort (and just about any other development effort for that matter.)

In this posting, I will share with you some guidelines regarding what to include in your definition (scope and business requirements) and your design. The list is by no means complete (hence the term guidelines), and everything on the list will not apply to every scenario. Feel free to contribute your own guidelines and lessons learned.

Note: The following guidelines do not cover topics having to do with Governance or Information Architecture, there is plenty of information available on those already (check out: New governance content for SharePoint published on TechNet and  SharePoint Governance – Key to a Successful Deployment on the SharePoint Team Blog.) These recommendations are meant to compliment that work, which I believe is equally as important.

So to what extent do we define? This will vary per solution, organization, and how much risk you are willing to take. At a minimal your definition should include a list of requirements that the business owners and project sponsors are willing to sign off on as the ultimate factors in determining the success of the project.

  • Meet with a representative of each of the primary roles; a system administrator, site owner, an author, editor, a contributor. Have them describe what they expect to do with the system keeping the focus on the “what” not the “how”. Your more complex scenarios may depend on additional roles, be sure you include those as well.
  • Document the functional and non-functional aspects of the current solution (if one is already in place). Don’t just focus on the negative aspects of the current solution, also look at (and document) the positives. Your solution should improve on the negatives without taking away from the positives.

    Note: Keep in mind that the current solution may be a manual process. If so, document it as well

  • When performing an upgrade, you may think there isn’t much to define.  Remember, we don’t want to take away functionality so its important that we capture what they have. At a minimum your scope and requirements document should include:
    • An inventory of the custom and/or modified site definitions, libraries and lists, as well as the sites that are using them (running prescan.exe will give you most of the site definition information you’ll need.)
    • An inventory of Content Databases
    • A list of unghosted pages (also generated by prescan.exe)
    • A list of any custom web parts
    • Custom Application and/or Administration Pages
    • Try to identify any applications that may be leveraging SharePoint via its web services.
    • Anything else being used that didn’t come out-of-the-box.

The design is more tricky, this is where I find that most projects fail; not always because of a poor design,  more often a lack of one. Do not confuse your scope or requirements documents for design documents. Every project needs a design. If the design seems obvious, then it shouldn’t take you long to write it down before you start doing the work.

For a standard/out-of-the-box implementation your design document should include:

  • A list of web applications that will be created including those for Central Administration, Shared Service Providers, and My Sites when applicable. (Alternatively these can be included in an infrastructure design or build out document)
  • The names and parameters of your content databases
  • A list of Site Definitions that will be used
  • A list of initial site collections and/or sites that will be created including the corresponding site definitions and content databases.


  • The SharePoint Lists and Libraries that will be created for each one of the initial sites
    • The columns that will be created with those lists or libraries in addition to the ones created out-of-the-box
    • The relationships between lookup columns and lists
    • Any associated workflows
    • The document templates
  • Any Content Types and Site Columns that will be created
  • Any Custom Groups and the corresponding permissions they will be given
  • The Content Sources, and Search Scopes (when applicable)
  • Custom Profile Properties and Property Mappings (when applicable)
  • Custom Managed Properties (when applicable)

Note: Always keep in mind that SharePoint is not a relational database and make sure the business clearly understands the risks involved with such designs. Recommend an alternative approach if you feel its the right way to go. Document your recommendations and any assumed risks and have the business users sign off on them.

When performing an upgrade make sure your design document includes the SharePoint 2007 equivalents of any custom web parts (some 2003 web parts may not be compatible), application pages, site definitions, list and libraries, that may have been created for the SharePoint 2003 environment. It may be a good opportunity to put governance in place and rethink the information architecture. Take a look at “Good SharePoint Upgrade Articles and Posts” from the SharePoint Team Blog.

For other scenarios requiring customizations or custom development such as; application pages, custom workflow’s, event handlers, and features; your design document should include the following in addition to the above mentioned items.

  • Document the methods and objects you’ll use in your custom application pages, web parts, and event handlers; making sure you understand the limitations ahead of time. Try to limit the number of assumptions you make by referencing the SDK as often as necessary. Consider using diagrams whenever possible.

    Note: Try to use the out-of-the-box web parts rather than developing new ones, you may find that there is little you cant do. Look to the Business Data Catalog and corresponding web parts. If the web part is going to be used for configuration purposes, consider using a custom application page.

  • Create use cases for your Visual Studio and SharePoint Designer workflows , documenting what the system should do and how its going to do it, not just the users. 
  • If your solution includes InfoPath forms; document all the groups and fields. Specify their name, type, and whether or not the group or field is repeating. Indicate which fields will be published in SharePoint.
  • Document how your solution will be packaged, consider creating multiple packages to separate unrelated Features, Application Pages, and/or Site Definitions.

Remember to keep the users involved, they’ll take ownership in the solution and be a lot more understanding when problems arise.

Technorati Tags: SharePoint, WSS, MOSS

SharePoint Solution Development, Planning for Success

Almost every successful development project goes through some sort of formal lifecycle; a process that involves a series of steps leading up to the completion of the project and its transition to a production environment. There are endless variations to this process, also known as methodologies or development frameworks, some of the more commonly known flavors include; Microsoft Solutions Framework (MSF), and the Rational Unified Process (RUP).

While many of these methodologies vary significantly in execution, most of them share many of the same principles;  define, design, develop, test, deploy, stabilize. Every one of these principles always appear in one form or another. Depending on how long you’ve been in this industry, you are probably familiar with them and their importance. If you are not, or simply don’t believe that they are all that critical, your probably just starting your career or perhaps should consider taking on another one.

So how does this process relate to SharePoint? In the same way it relates to any other Application Development project. Yet somehow, with SharePoint solutions, many of the principles are often disregarded. I know that’s a general statement, but based on what I see every day in the SharePoint development forums, comments on blogs, and helping out my clients; I find there is a big void in the  SharePoint solution development process, and its spreading more every day.

Luckily the cause is not difficult to identify, and having any sort of formal development experience (particularly in enterprise environments) the remedy is clear.

I believe that the cause itself arises from the very nature of the product, how its sold, how its perceived. The product itself, or its perception as “a product”, rather than a platform or series of services, leads most businesses to believe that it can simply be implemented out-of-the-box. While Microsoft and many others in the SharePoint community have stressed the importance of Governance, and Information Architecture (which have been very well perceived,) I find that that these topics simply aren’t enough. They help address many of the operational and organizational issues having to do with a successful SharePoint deployment, but do very little in regards to the functional aspects of the solution. As a result, the developers end up having to make many last minute decisions, the solutions aren’t very scalable (at least not from a functional standpoint), and become very difficult to maintain. In the short term, the developers and support personnel become very frustrated with the solution, in the long term nobody is happy.

The remedy is simple, and likely already in place in your organizations software development methodology. I find that almost every problematic SharePoint project lacks a clear definition and a design, this is where the real problem lies.

In one of my next blog posts (likely the following one), I will share with you some guidelines on what to include in your definition and design documents.

Added July 7th, 2008 – I’ve posted the follow up to this post:
SharePoint Solution Development; Define (Requirements Gathering) and Design Guidelines

Technorati Tags: SharePoint, WSS, MOSS

Create a free website or blog at

Up ↑

%d bloggers like this: