@cyberslate: INFOSEC Preso on Security and Privacy in SharePoint 2010: Healthcare - Life in Caps Lock: cyberslate's posterous

via lifeincapslock.com

Some great information here about using SharePoint in HealthCare.

Compartmentalization with a robust security grouping strategy can pay dividends. in many cases SharePoint can be used to manage workflow because the process of managing the workflow does not require visibility to PHI/PII information. In these cases separate and compartmentalize the PHI/PII data and control access through security groups.

I built this capability in SharePoint 2007 using associated lists. This allowed teams to review case workload and progress without having to see member information. Yet the member information was accessible via a simple hyperlink, providing the viewer had adequate security rights.

As is correctly pointed out, this needs Administrator involvement from the outset and ideally the creation of utilities and web parts that support this approach so that we make it easy for site administrators/developers to create departmental and team workflows that remain HIPAA client and don't divulge PHI or PII to unauthorized personnel.

Posted via email from ekivemark: pre-blogspot

Microsoft has a dirty SharePoint secret

At work, like probably a lot of people I am running Windows XP with Office 2003 and Sharepoint 2007. I have been battling a problem with Sharepoint and Excel for some time now. It all centers around the Datasheet view in SharePoint. This seems like a useful feature that lets you manipulate Sharepoint lists as if they were a spreadsheet. If only it would work reliably.

When I try to use Datasheet View I get an error telling me that "The list cannot be displayed in Datasheet view for one or more of the following reasons:

• A datasheet component compatible with Windows SharePoint Services is not installed,
• your browser does not support ActiveX controls,
• or support for ActiveX controls is disabled."

It seems I am not alone with this problem. Microsoft Help and Support does tell us that you have to use Microsoft Office 2003 or 2007 Professional edition. That is the first open dirty secret. With all the differing versions of Office that were sold you have to use the Pro edition to get the necessary activeX components to enable this functionality. So, if you are a small business and purchased Office Small Business Edition for your desktops and then went and bought the Microsoft Small Business Server with SharePoint then you are probably going to be stung for some upgrades.

The other dirty secret is more difficult to fix. It appears that SharePoint can't cope with you running multiple editions of Office. So, if you upgrade to Project 2007 or one of the other newer versions of Microsoft's Office productivity suite but don't update the core Office 2003 Professional version then you will probably find that the datasheet view in SharePoint stops working for you. It appears that latest owssupp.dll file (and possibly other dll's) are not backward compatible. This hybrid situation where part of Office 12 (ie. Office 2007) gets installed alongside Office 2003 is a situation that Microsoft can't cope with. I also saw this when I installed a trial version of Sharepoint designer. When the license expired the datasheet view stopped working and when I uninstalled Designer it didn't fix the problem.

With a growing dependence on web-based applications the datasheet view error is a nasty one because it actually causes Internet Explorer to crash. If you use Firefox with IE Tab it will also crash Firefox.

Right now I am running with Outlook 2007 and Office 2003 and I am wondering if this hybrid setup is a continuing cause of the problem.

I know it is in Microsoft's best interests to push us to upgrade to everything 2007 but they should be able to support their own stable of products that span across versions. Maybe this just indicates that not only is the Windows platform creaking but the Office System has also got to large and unwieldy.

It is going to be a common situation, particularly in this economy where organizations may upgrade parts of the suite in order to access enhanced functions but leave other parts of the Office suite in place on the prior version. I think Microsoft's decision to radically change the user interface in Office 2007 may make more companies reluctant to change because of the retraining costs that they will incur.

Telling us to upgrade everything to 2007 is not an acceptable answer. However, when Microsoft tells their customers who bought 30Gb Zunes to just wait 24 hours to fix their the leap year bug that stopped the devices working on December 31st, you know that we shouldn't hold our breath waiting for a fix. All this just confirms my thinking that simpler, browser-agnostic, web applications have a bright future.

UPDATE - I may have worked a fix for this problem. This is what I did:

I did a search on my C: drive for owssupp.dll.

I found two versions in these directories:

• C:\Program Files\Microsoft Office\OFFICE11
• C:\Program Files\Microsoft Office\Office12

Since I am using Microsoft Office Excel 2003 (ie. Office 11 Pro) I renamed owssupp.dll in the Office12 folder to owssupp.dllx.

I then restarted my PC. So far I seem to be able to get the datasheet view working. It will be interesting to see if anything is broken in Outlook 2007.

Battling with SharePoint

Some consider SharePoint 2007's key competitive advantage to be "the breadth of integrated collaborative and community-based applications that are provided out of the box or can easily be developed with SharePoint rich platform services". It was certainly the point Lawrence Liu was making on his blog.

In practical use SharePoint 2007 leaves a lot to be desired. It may be the way it is implemented in some environments but it seems to get used primarily as a "souped-up" shared drive. Actual solutions built around SharePoint seem to be either disjointed or require custom configuration using Visual Studio or Frontpage's successor - SharePoint Designer.

The Wiki functionality in SharePoint 2007 is basically unchanged from the 2003 version. It is pathetic in comparison to other Wiki products. Have you tried adding attachments to a page on a SharePoint Wiki? It is a multi-step process that involves uploading files to a shared document library and then getting the shortcut and posting it in to the page you are editing on the wiki. This is not something your average user is going to want to do. Trying to find workarounds for these weaknesses seems to give further proof that SharePoint is not a collaboration platform. It is a development environment with a set of collaborative components that require professional development resources to configure to make usable solutions.

Trying to implement workarounds reveals other weaknesses. I would love to find solutions for these challenges that can be implemented by a site owner and not require system administrator privileges. If you have suggestions please let me know. Here are some of my attempts at workarounds:

Modify the wiki page to add an extra web part with a document library.

Now this works. You can go to site actions for an existing page and modify the page to add a web part. Choose a document library and you can have an add document link. So far so good.

The downside to this approach is that you are only modifying the configuration of that individual page. There does not appear to be a way to modify the default wiki page layout that all pages use.

Modify the Edit Wiki Page

This does not work. The Site Actions drop down does not let you modify the edit page. This means you can't add a web part to add a document library list.

Let's Forget the Wiki and create a Document Library

In this scenario I want to create a library with a multi-line text field that can have a file attachment. If you start with a standard document library you get all the upload functionality but there seems to be no way to add a record without uploading a file.

If I want to upload a link to a web page I can't do that. Using a URL instead of a document gives an "Error on Page" in the status bar. The record refuses to be created.

Other limitations also show up. For example, if I add a description field to the record it can be a multi line text field but you can't use enhanced text. Consequently font, formatting and hyperlinks are out.

Ok, so let's create a custom list instead

So there are problems with using a document library. Let's start with a custom list. Yes we can create rich text multi line fields so we can use fonts, formatting and hyperlinks. However, attaching a file is an extra step. What's more, once you have attached a file there appears to be no way to launch the attachment from a list. You have to open the record and select the attachment.

At least with the custom list solution I can include URL links and attach files but the user interface is not consistent with the standard document library. There is also no option, as far as I can tell, to add the document information that matches the standard document library.

Designed for Developers

My trials and tribulations attempting to do simple things that have been available for years in wikis and even in Lotus Notes seem to confirm that SharePoint is not a collaboration platform. It is a development platform with collaboration components.

Are You choosing sharePoint?

If you are thinking about using SharePoint in your organization. Yes, it is better than a shared network drive through the use of it's simple version control features. However, if you are looking for a collaboration platform then either look at one of the wiki platforms, like SocialText, or be prepared to invest significantly in additional third party web part components for SharePoint, or in maintaining a team of development resources that can customize SharePoint to meet your needs.

RSS Tricks at BarCampRDU

Nathan Gilliatt gave an interesting talk on RSS tricks. The first example was using feed informer to consolidate feeds.

AideRSS filters RSS feeds based on popularity based on comments, posts to del.icio.us etc.

Feedblitz provides RSS to email integration

Dapper.net is another site that lets you manipulate RSS feeds.

But how can you do this inside the enterprise firewall?

You could use Presto from JackBe?

Another alternative that I thought of is to install the Open Source version of SocialText and use the platform to collect RSS feeds and re-purpose those feeds via a wiki page.

Microsoft's SharePoint is not an option if you want to aggregate or filter SharePoint RSS feeds because the RSS feed handler in SharePoint does not handle the authenticated feeds produced by SharePoint.

Campers deciding the Agenda at BarCampRDU earlier today.

SharePoint and shifting the Culture

Like it or not Microsoft is tightly embedded in many corporations and the freely licensed Windows Sharepoint Server (WSS) makes the Sharepoint collaboration experience an easy decision for many organizations that don't want to take the time to consider their real needs.

To me SharePoint is a fractured product. It perpetuates the document centric view that has been at the heart of the Office suite for so long. do you feel the frustration of everything being an extra click away because the information you are looking for might be buried in a word, excel or powerpoint document? Do you get frustrated by a word document being loaded inside the browser and in a moment of distraction you close the window and realize you just closed the browser and need to relaunch and navigate down the myriad menus and links to get back to where you were?

I am also coming to a realization that many organizations do not do themselves any favors by the way they deploy SharePoint. Given that the Search tools leave a lot to be desired the tendency to replicate the Shared Drive structure in Folders within libraries in SharePoint leads to a frustrating experience when searching for information. This then is compounded when SharePoint is implemented as a lightweight document repository. The result is often document libraries that are lacking the context and discussion around the documents. In the basic Sharepoint implementation the Discussion libraries are self contained and make it a frustrating experience to link back to other content.

So how can we make things better? How can we encourage a more forward thinking deployment of SharePoint that helps to change the culture to encourage real collaboration amongst team members?

I am facing these challenges on a daily basis. As a result I have been thinking about some principles for SharePoint sites. A set of principles that can encourage collaboration and improve information accessibility. Here is my list. I welcome your contribution to improve this list.

SharePoint Sites - Principles for Collaboration

• Don't reproduce the shared folder in SharePoint sites and libraries
• Categorize information in lists to enable filtering, sorting and grouping
• Keep text out of documents
• Hyperlink whenever possible
• Enable comment and discussion around content
• Make sure version histories are enabled
• Make information openly readable whenever possible

Don't reproduce the shared folder in SharePoint sites and libraries

Sharepoint makes it easy to create folders inside libraries and sites but it doesn't make it easy to navigate back up through the folder structure.

Wherever possible create additional fields in lists and libraries that allow pseudo folders to be created and then create views that sort, group or filter by those pseudo folders.

Create a category field to describe the type of document. Use this field so that you avoid creating libraries for presentations, white papers, templates and other documents that fracture the overall picture. Setup views to group and filter by document type. When used in conjunction with pseudo folders this allows all documents for a given subject to be seen in one view.

Categorize information in lists to enable filtering, sorting and grouping

As per the previous point. Use additional fields in lists to allow information to be categorized and viewed logically without requiring folders to be created to segregate information.

Keep text out of documents

Use the Wiki library function and the Rich Notes fields in lists to allow users to enter information directly in SharePoint. This avoids the double or triple mouse click to load a word, excel or powerpoint document just to find it doesn't have the information you are seeking.

Use the notes and comments fields when documents are uploaded to allow a description of the document. This can be more helpful than the sometimes cryptic document file names.

Hyperlink whenever possible

You don't need to copy information if you can link to an existing source. Use this capability to make it easier for users to find information as they navigate documents and lists. Hyperlinks can also be used to bring users back to SharePoint and keep people engaged with the sites you create.

This is a practice that is slow to be adopted by many users. Therefore as the site "Gardner" it falls on your shoulders to edit content to add in links when you know they are available. Lead by example!

Enable comment and discussion around content

Don't create a replication of the shared folder where libraries and sites just contain documents. Create A Wiki library and encourage comment in the pages of the Wiki. As per the previous point, link back to content in the document databases.

One simple trick to encourage comment, given the barebones nature of the SharePoint Wiki library, is to finish every Wiki page with a "Comment" headline and a tag "Enter your comments about this page by clicking edit. You can even make "Edit" a hyperlink that is tied to the Edit URL of the page, just copy it from the browser address bar.

Make sure version histories are enabled

I often encounter libraries and sites where versioning of documents is not implemented. Switch this on! It goes a long way to reduce the fear factor amongst new users when they realize that they aren't destroying content if they make a mistake.

Make information openly readable whenever possible

In many organizations the temptation is to over use the security features in SharePoint. The more you have tight controls the harder it becomes for users to make changes. Simple edits, such as for spelling errors become bigger production efforts.

Think very carefully about security. You may want to create a sub-site for Work In Progress that is not ready for prime time and limit the access to just the direct team members. The rest of the site may well be okay to grant at least read only rights to a much wider audience.

Remember the more you tighten the access reins, the more time you will spend diagnosing access issues and granting and revoking access rights.

What have I missed?

That is my seven point list. I am sure I have overlooked something. Let me know your thoughts. What would be your top principles for creating a great SharePoint site that encourages collaboration? Share your thoughts by leaving a comment.

Enterprise 2.0 concerns

Andrew McAfee wrote recently about the Questions he has been asked about Enterprise 2.0. As I scanned the list there was one question I have been asked on multiple occasions when talking about the use of Wikis inside a company. The question usually goes something like this:

"What happens when somebody posts information that is wrong?"

This can quickly lead in to a discussion about the need for a formal editorial committee for any material posted to the wiki.

My response to head off this line of thinking is this:

• We are no worse off than we are today, indeed we may be much better off
• The concern behind this question usually comes from people experiencing incorrect, or unauthorized, information being distributed via email
• In the email paradigm erroneous information can persist for much longer depending upon who is included in the distribution list for the email.
• In the Wiki paradigm (usually) anyone can have visibility to information and so the error can be caught much more quickly
• Once the error is caught there is only one copy to correct, unlike email where the error can persist in people's email archive.
• What you tend to see is that people with specialist interests will monitor topics of interest to them and will catch errors earlier in the process, all without the need for heavy handed editorial control.

100 Million is a lot of extra clicks

Microsoft is claiming great market penetration with Microsoft Sharepoint. According to CIO Magazine, and other sources, Microsoft has sold over 100 Million licenses for Sharepoint. Now Sharepoint has a lot of great features and I am often asked how it differs from Wikis, blogs and other socially enabled applications.

Microsoft Sharepoint has its roots in document management. The Wiki component is Sharepoint breaks some of the fundamental rules of the Wiki such as versioning of content. The wiki feature set is very weak.

Microsoft's approach to the Wiki is to treat the Wiki as a document. This is fundamentally different from most other wiki designs where the Wiki is the environment. Just try linking from a page in one Sharepoint Wiki document to a page in another separate wiki document.

Given Sharepoint's roots in document management the way I have seen Sharepoint implemented is around lists of documents. I have also seen the lists arranged in folders. Perpetuating this metaphor makes Sharepoint only marginally better than the Shared drives it often replaces or supplements.

This type of organization where you have lists of documents and, if you are very lucky, a description of the document leads to all of the information you need being at least an extra click away. This is the biggest difference between Sharepoint and Wikis. With a Wiki you see the content with context. In your typical implementation of Sharepoint you see a list of documents that you need to click in to in order to determine if it is what you are looking for.

So really it is not 100 Million extra clicks. Instead it is in fact The average number of sharepoint documents accessed in a given day by a user multiplied by 100 Million. Now that is a lot of extra clicks!

Document Manipulation and Sharepoint

Sean Lemon of Universal Forest Products (UFP) presented a user case study on "How to Link Process Workers to Document Management, Imaging and Workflow via SharePoint"

My guess, before the presentation starts is that Sharepoint is not the total answer. Instead it is part of the solution. We should not be building monolithic solutions. We need to concentrate on interfaces that allow information, content and processes to move in and out of the best applications for a particular task.

AFP uses an Enterprise Content Management (ECM), onBase from Hyland Software and Sharepoint 2007. While both offer workflow Sharepoint is the Intranet and collaboration tool and ECM is a document centric workflow and final retention platform.

Integration came about by creating a portlet that enabled a window from Sharepoint in to the ECM platform.

The next phase in this evolution is to migrate e-forms to InfoPath and then provide ECM to Sharepoint integration so that documents can be retrieved from Sharepoint and deposited in to the ECM platform.

The bottom line: This reinforces yesterday's Sharepoint presentation that points to not using Sharepoint for document imaging - use an application that is designed for that purpose and provide integration to the Sharepoint platform - if Sharepoint is being used for workflow purposes. 

Everything you might not want to know about Sharepoint

Gartner's  Karen Shegda reviewed Microsoft's swiss army knife product which is Microsoft Office Sharepoint Server (MOSS) 2007.

The new features are wikis and blogs plus people search.

Content management had major updates and records management to keep DoD happy (Dod 5015.2).

The MOSS is not seen as an Enterprise Content Management product. MOSS builds on Windows Sharepoint Services (WSS) and on top of basic Windows File Services.

The MOSS portal provides Search, personalization, news, presence and calendaring. We will see Sharepoint increasingly integrated in to the Unified Communications Server stack.

The claim is that team collaboration is a sweet spot with team sites, task management, wikis and blogs. However, from what I have seen of the Wiki capability it is still well behind the curve in comparison to other wiki products such as Socialtext.

One content management gotcha is that compound documents are not handled by Sharepoint.

MOSS has multi-layered security. Site administration, Service administration and central administration.

Integration of MOSS depends on your level of commitment to the Microsoft Ecosystem. However, I have seen instances where things like datasheet edit capabilities get disabled if you have a mixed Office 2003/2007 product set. For example Office 2003  with Project or Infopath 2007. Beyond the Microsoft Ecosystem integration is required. Like a lot of Microsoft software - you can make it do just about anything - provided you want to sit down and cut plenty of custom VB or .Net code.

My experience is also that you need to buy in to the Microsoft stack. Don't try running Sharepoint using Safari on a Mac. If you want to run FireFox on Windows you are best to install the IeTab add-on for Firefox that basically run Internet Explorer inside Firefox.

Succeeding with Sharepoint

• Set up governance
• Set a policy on the life of team sites
• Develop a high-level common taxonomy. This is especially true in compliance-controlled environments like Financial Services and Healthcare.
• Create an approval process for sites
• Build a library of useful templates and third-party tools
• Determine who owns the user experience for different classes of users

Some third party tools bridge Sharepoint Gaps

Quest software - management tools

Infonics and Syntergy - replication tools

F5 Networks and Riverbed - WAN Accelerators

Casahl - Content migration

Don't overlook the substantial supplemental costs:

• Additional database licenses
• internet server for public sites
• Office 2003 or 2007
• MOSS requires a standard or Enterprise Client Access Licence (CAL)
• For offline access to Sharepoint you will need Groove desktop clients

First steps

• develop your content management strategy before acquiring technology
• Focus on people and behavior. Fit tools to the process. Don't bend processes to the tool.
• Prioritize for flexibility. Avoid monolithic design. Build in a modular manner.

Sharepoint and Content Management

One part software and four parts professional services. In other words there is a lot of custom integration required.  

What is the difference between collaboration and an Intranet. Collaboration is dynamic and often real-time, two-way and asynchronous. The Intranet still tends to be a one-way publishing paradigm.

Sharepoint and Document Imaging

Sharepoint is only suited to lightweight document imaging and workflow. It is not designed for heavyweight transactional document imaging applications.