Tech Trek – 2011.01.22 Sunday

I’ve recently had a conversation with a colleague on the appropriate platform to publish tribal knowledge that he would like to share. With this in mind, a couple of question arises on the social computing capabilities of SharePoint so that we can make better use of the technologies:

  • What is the difference between blogs, wiki, and discussion forums in SharePoint?
  • When is the appropriate usage of each technology?

Here is a comparative chart the various criteria for choosing one format from another.

Architecture Categories
Wiki Blogs Discussion Forum
Standalone Site Can be implemented as a self-contained site but may also be included within a collaborative site Yes No, included as list in a site
Structure Open structure i.e. may differ from page-to-page More structured exchange of ideas Structure is based on the target audience of the forum
Model
(Author-to-Audience)
Many-to-many One-to-many Many-to-many
Authors Can have multiple contributors that are managed by many users Can have multiple authors but typically are moderated by a single author/team Can have multiple contributors but typically are moderated by an owner/group
Audience * Typically published for a large audience Targeted audience i.e. Developers, Finance, Sales, etc. Limited to the specific site audience
Ownership  Per page basis Per article (item) basis Per topic item basis
Editing Shared editing that may result into resolving conflicts manually Typically authored by an individual and approved by a moderator or blog owner Typically Q&A or challenge and response format
Community feedback Comments aren’t available, by default but can be added to solicit feedback Comments are available by default, but not necessarily intended to solicit feedback Expectation is to receive comments or feedback
Typical Uses * General knowledge base repository, projects, or policies and procedures (permanent) Journal used to communicate news, events, tips and tricks, share expertise to other team members (mixed) Typically used to address a specific issue, or bug (ad-hoc)
Content Categories
Wiki Blogs Discussion Forum
Content Type * Authoritative content i.e. should be approved for publication Opinion-based content Speculative topic i.e. may not produce a definitive answer to an issue
Content Length May include lengthy content or topics Short and ideally a specific topic per posting Varies based on the issue difficulty
Content Frequency Less frequent changes and/or longer cycle for reviewing content More frequent, or recommends a regular posting cycle As needed depending on issues encountered
Organized By (Format) Pages by topic or categories Articles in reverse chronological order Title or date; may want to create separate forums for each functional area
Search Filters Uses tagging mechanism and popular tags Filtered by category and on a monthly basis Search items by Title and Date but can include additional columns as needed
Content Columns Offers some flexibility when using Enterprise Wiki page templates Title, Body, Category, and Publication Date Subject and Body but can include additional fields as needed
Revisions Pages keep revisions for historical purposes to allow users compare changes New content supersedes previous postings; revision overwrite content and author is responsible for describing changes Updates are communicated through replies in the thread
Recommendation Reuse shared pages or elements; Convert textual content with audio or visual components Intended for a specific team, or audience rather than creating separate blogs for each individual that users need to subscribe Targeted issues that can be addressed in isolation i.e. create separate entries based on category and mark them as resolved or not

In summary, these are the key criteria when implementing one of the above-mentioned options:

  • Who is your target audience?
    Will your readers include the whole organization/enterprise, or a specific interest group?
  • What type of content do you intend to publish? (authoritative, opinion-based, or speculative content)
  • What uses is the content geared for? (permanent, ad-hoc, or mixed)
  • Who will be the primary moderator/s of the content?

As indicated, there is no one-size fits all rule when implementing social computing features within an organization. You can use a hybrid approach to achieve optimal collaboration and participation from users.

In an enterprise environment, the general rule to keep in mind is not having anonymous users to minimize posting inappropriate content, or accidental sharing of confidential information.

Tech Trek – 2012.01.22 Sunday

I’ve recently updated an InfoPath form template for a project and ran into the following Microsoft Support issue KB2554288.

Columns published from InfoPath fields are recreated when the same InfoPath form template is re-published to more than one document libraries in a SharePoint site

Unfortunately, I read this knowledge base article after I had already published the InfoPath template into a second form library to “test” the changes I plan to apply in production. I didn’t intend to implement the suggested resolution of publishing the template as a Site Content Type, or creating Site Columns since it isn’t going to be reused anyway.

With this data at hand, I proceeded to delete the second library even before re-publishing the production form template. As indicated, the promoted columns were re-created when publishing a form more than once within the same SharePoint site. In my situation, this resulted into the following issues to the original form library:

  • Promoted columns were removed in list views
  • Calculated columns resulted into invalid values (#VALUE) even if column names are the same
  • Custom workflow lookups didn’t resolve the promoted columns

Luckily, my form was not too complex but I had to perform these steps to correct the form library:

  • Re-create the list views
  • Re-create the calculated columns
  • Modify custom workflows in SharePoint Designer and later re-published them to the site

GAPS AND RECOMMENDATIONS
It was a good thing that I had backup of the configuration settings so I will able to re-create them as needed. Thus, it would be nice to have a SharePoint tool to create documentation about  configurations. Also, the ability to restore custom workflow would be helpful in case of a worse-case scenario of re-creating the library or list.

SUMMARY
The intent of this post is to shed light on some of the nuances of InfoPath development as compared to the traditional deployment procedures into a test or staging environment. Thus, it introduces additional work for SharePoint Administrators when applying “change control” practices and poses a challenge when trying to adhere into legal compliance scenarios.

It does take a different mindset coming from strict software configuration management (SCM) principles in my previous work experience. What we’ve done in our organization was to store application configurations in transactional database tables and XML files coupled with version control system which made auditing changes more feasible.

Tech Trek – 2011.09.02

It was a nice work day of summer and first thing in the morning came a report from a user that SharePoint search is not working. So I went on wearing my “administrator hat” and tried to troubleshoot what happened to the environment. First order of business was if I can replicate what error occurred, unfortunately, it’s much worse that I thought since even clicking a web part header returns an error.

So, I checked out the event logs and here is what I’ve found:

WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+ HostingManager/38898923

Exception: System.ServiceModel.ServiceActivationException: The service '/<guid>/MetadataWebService.svc' cannot be activated due to an exception during compilation.
...
Process Name: w3wp
Process ID: 5832

In the interest of time, I’ve highlighted the key section of the error message which was a failed worker process (w3wp). Next step was to find that process ID that was affected in particular so I’ve used the following method to identify the list of worker processes in Windows 2008:

c:\windows\system32\inetsrv> appcmd list wp

With IIS Manager opened, I was able to isolate the web application pool that was giving out this error and performed a “recycle” operation to correct the issue. Smoke test proves to be successful by executing the search that was earlier reported. As it turns out, the affected SharePoint server recently had a “pending” Windows Update that required a full reboot to complete the patch.

    Tools Used:

  • Event Log viewer
  • AppCmd using Command Prompt
  • IIS Manager
  • Windows Update utility

Now, if I can only cast “dispel magic” on such situations — life would be easier for a SharePoint adventurer.

Tech Trek – 2011.08.28

One of the hurdles for adopting into new technology, or moving into a new system is having to perform double-entry. A common complaint that I receive as a solutions designer is why users have to move data if these already exists in another format. Another side effect with double entry is the possibility of inconsistencies and the time it takes to re-key such items. As the adage says, “if it’s not broken, don’t fix it!”

This is usually the case for SharePoint lists since users are already familiar with other tools that perform the same function e.g.

  • Email messages as Announcements
  • Address book entries into Contacts
  • Meeting requests into Calendar, etc.

I’ll focus on the particular scenario for sending meeting requests using Outlook. Users are already familiar with sending an invitation through the email client and one way to alienate them is forcing them to re-enter items so that it can appear in the calendar. Unfortunately, information sharing on the web is not a worthy justification if it will result into more work for users to perform their “actual” job.

Thankfully, there is a feature to receive incoming emails since the SharePoint 2007 release. Again, my intent here is not to illustrate a step-by-step guide but rather to provide the concept on making technology work for you. This reduces the barrier for the organization by configuring a SharePoint list to receive incoming messages and instructing users to include such email address in their meeting requests. On the plus side, one thing that SharePoint provides is the ability to have those items to exist in a central repository so new employees that was not previously copied with such message can go back to a historical list that is available to them.

Problem solved. I’ll post other Microsoft Office integration points as additional value-add benefit that justifies the effort in adopting SharePoint.

Reference:
Configure incoming e-mail in SharePoint

Tech Trek – 2011.08.15

PROBLEM:
I was building an InfoPath form that requires security from certain users of the solution. One of those involve preventing access to the following context menu and ribbon menu options:

  • Send To … Download a Copy
  • Open with Explorer

Unfortunately, these options becomes a loophole if they are available for the security mechanism that I was planning to enforce through browser-based form services. Note, configuring the “Default open behaviour for browser-based documents” in Advanced settings of the form library does not prevent a user from selecting the “Edit in InfoPath” option from item menu. Downloading a local copy allows the end-user to see any restricted views while allowing the “Open with Explorer” option opens the WebDAV folder that could give access to other files in the form library. Not good!

SOLUTION:
As I conduct my research, it’s amazing how many programmers came up with different solutions to resolve such issue. Although, some are simple to implement one key criteria that I had in mind is a “no-code” solution since that is what SharePoint offers in the first place. So with that principle applied, I ended with configuring the permission levels to disable or hide such menu options in both the 2010 ribbon menu and item dropdown without opening SharePoint Designer that could affect any future upgrade issues.

Note, I’m not going to provide the steps here since most SharePoint administration references would walk through such configuration but the key site permission options to note are the following:

  • Use Remote Interfaces
  • Use Client Integration Features (removes Edit in … option)

The best practice is to copy a default permission level and remove the particular permissions that you want to exclude. Just a reminder that disabling the above permissions may include other features that you may want for your site so make sure to “test early and test often” with different accounts that would use the system. Lastly, I created a separate list view page that is similar to the All Items view in a secure document library so that only site administrators have access to it for additional security measures.

The end result, problem solved without custom coding.

References:
Technet User Permissions and Permission Levels (SharePoint 2010)
Technet Configure custom permissions (SharePoint 2010)