A Matter Of Degree

Six (additional) Worst Practices for SharePoint

This is broken, originally uploaded by Lodigs.

I recently saw that Ben Curry (of Mindsharp and the SharePoint Best Practices Conference) has a list of the Top 10 Administrative Bad Practices for SharePoint. I definitely agree with his choices.

The SharePoint Practice team at my company has been keeping our own list of Worst Practices for SharePoint, and I'd like to take this opportunity to expand on Ben's list and add a few that we have seen over the years.

Please note - this appears to be a list of recommendations; IT IS NOT.

1. Give all your power users and content owners Full Control.
When you can't decide which level of rights to give to your content owners (for example, those individuals who will need to create new metadata categories and build new lists and libraries as well as contribute content to a site), you can be confident that Full Control will give them all the rights they need, but there is a better way. Manage Hierarchy is often an acceptable level of security, which will let those power users do more than contribute, but not do irreversible damage to the site.

2. Don't use metadata to categorize documents or databases; just create a new folder, list or library every time you need a category.
While there are often reasons to create new lists and libraries to segregate content, and there can even be good reasons to use folders within a list or library, this shouldn't be your default content management model. This Worst Practice is related to Number Three:

3. Don't use metadata to categorize documents; just put all the information in the filename field.
Companies with document naming conventions are often used to long filenames that give a lot of information about the document. By using metadata instead, SharePoint (and similar content management systems) can free you from the need to keep all the information in the filename, and provide greater power for filtering and finding documents.

4. Use your old legacy servers for your new SharePoint implementation.
You're not sure if SharePoint is the right product for you, so you'd like to give it a test-drive without making a big investment in hardware.  Unfortunately, what we've seen many times is that running SharePoint on underpowered servers and forcing it to share space with other legacy applications may not give you an accurate test-drive of the product, and in fact could cost a significant amount in terms of time spent troubleshooting.

5. Don't set up any test user accounts.
When you're building out SharePoint, you're most likely logged in with the powerful permissions of a farm administrator, site collection administrator, or site collection owner with Full Control.  As you prepare for launch, moving around the site and testing functionality, you can see and do everything you need to.  Your end-users with Read and/or Contribute rights may have a very different experience - and you don't want to hear this from them on the day of launch.  Create, at the very least, one end-user test account, so that you can log in and out as needed to test your site.  Ideally you would create one for every location, department, or high-level user role, especially if you're using features like Audience Targeting, so you can really see what your different user groups see.

6. Use a folder or document library called “Old.”
Like a lighter held aloft at a concert, this practice keeps the spirit of the file share alive in your new SharePoint implementation.  Folders with names like "Old," "DO NOT USE," "Don't Need," and "Blurry Photos" can be a comforting structure for the end-user who's missing that big old P drive on the network.  In a system where content can easily be surfaced by Search rather than by browsing, however, it may not be apparent to the searcher that the likely-looking filename they've turned up is sitting in the "_delete" folder. 

For your long-weekend enjoyment, check out some more Worst Practices in the physical world at the "There I Fixed It" site.

How the Apollo 11 moonwalk became a tagging and records retention tale of woe

Stepping Onto the Moon's Surface, originally uploaded by NASAImageoftheday.

Today is the 40th anniversary of the Apollo 11 moonwalk, and this morning's NPR story "Houston, We Erased The Apollo 11 Tapes" is a classic tale of tagging, search, and records retention policies (or lack thereof). The article and broadcast are really worth a read/listen, but to sum up:

The original recording of the moonwalk was not in a format that was compatible with television, so the recording was converted for the TV broadcast in 1969 - and degraded in the process. Engineers knew there was a better-quality recording from the camera on the moon, but for years they couldn't find it. They had to search a vast repository of content using much-used terms like "Apollo" and "tape." It turns out that the recording was most likely recorded-over due to NASA's increased need for magnetic tapes in the 1980s.

This scenario makes me think of my clients - many of whom have expressed to me, in the process of converting to a SharePoint implementation, the notion that "any content over five (or three, or six, etc.) years old is worthless." I understand the concept - policy and regulation changes, business and market trends, and fresh research and information all change the relevance of older content. But as the NASA story shows, you may not realize now what's going to be gold in 40 years.

If you're managing content (and who isn't, whether on an organizational or individual level?), do you have record retention policies in place to expire content after a certain time, and if so, are you notified to check the content first, or is it automatically deleted? Are you at risk of having files erased due to exigencies like lack of storage space? Are files backed up on a regular basis, and if they are, could you restore those backups successfully? Have "delete" permissions been given to those who may not fully understand the importance of the content? In your search results, are the "gold" files getting buried under layers of more recent sediment?

NASA invested time and resources to restore and improve the quality of the recordings they did have, since they couldn't access the original. While you're pondering these questions, you can see the video here. (Personally, I'm a fan of the grainier original look; by removing noise they've flattened out some of the detail, a metaphor to explore another time...)

And a nod to you conspiracy theorists out there - pretty convenient that they "lost" those tapes, eh?

Issues with Manage Content and Structure Move / Copy functions in MOSS 2007

I like the convenience of using Manage Content and Structure to move batches of files from one document library to another, while maintaining their metadata (custom fields as well as metadata like "modified by" are brought over from the source library to the target library).

However, I have been seeing some strange and concerning results, mostly having to do with content types.  In a recent example, I had a library of documents with a yes/no checkbox to allow for displaying certain of the documents in a view on the home page.  Another library needed to be merged in with this one, which had the same yes/no checkbox (same column name).  I recommended that my client move the files from one library to another using Manage Content and Structure.  After she did this, she reported that the documents from the merged library were not apperaing on the home page view even though she had checked "Yes."

When I looked more closely at the document library, I saw that there were now two identical fields for the yes/no choice in the same document library.  SharePoint had copied one over and kept the original - and the values were different in each field.  (In the field properties, I saw that the system had appended "0" to one of the column names on the back-end.)

In this case, it was a simple matter of making sure all the data matched from one column to another, and then deleting the duplicate column.  But in some cases (e.g., when the Move function added the "Publishing Start Date" and "Publishing End Date" fields to a document library) I've had to switch on "Allow management of content types" and hide the extra fields that were added during the move process so that my end-users wouldn't be confused by the newly-added fields.

Consider this a word of warning - Manage Content and Structure may beat Explorer View in terms of convenience and speed when moving batches of files, but it can cause unintended outcomes that could take you more time to troubleshoot and fix in the long run.

MOSS 2007 folks - If you're using the Site Directory web, put an alert on your Sites list!

I'm at a client site today, finishing up a MOSS 2007 intranet for launch this week.  I just viewed the Categories tab on the client's Site Directory when logged in as an end-user.  We customized the categories to reflect the organization, and filled them out with links for each division.  As an admin I can see five links under a particular division, however the end user could not see any of them. 

The Sites list (which can be found under the Site Directory tab, by choosing View All Site Content) can be manually built to include links either inside or outside your intranet, but also receives automatic entries anytime someone creates a site and checks "List this new site in the site directory." 

 

These entries go into a "Pending" state even if they're created by an admin (which could be defined as in the "Owners" group, and/or having Full Control rights over the site, and/or a Site Collection Adminstrator). The result is that only admins can see the Pending links. If there are content owners with Manage Hierarchy rights who are out there creating sites, the admins have no way of knowing when new links have been added to the Sites list.  The Site Directory is being populated but none of the end users will be able to see the additions. 

To ensure that your Site Directory is up-to-date and useful, set an alert on the Sites list to notify at least one of your site administrators when a new link is added.  This seems like simple common sense, but my thought in posting this is that if it hasn't occurred to me in 2+ years of working with MOSS 2007, there's a chance that others have missed it as well.

Site Column Best Practices - whether to use a list lookup or choice field

The question came up this week of whether it's preferable to use a lookup or choice field for storing data within a site column.

I don't have a definitive recommendation, but I can offer some pros and cons, gleaned from various sources:

• A list lookup will let you delegate management of the master list to an end user simply by giving them elevated rights to the list; to manage a site column you must be a site collection administrator.

• A list lookup will allow approvals for selection choice changes, and will allow audit trails (great point by Nadeem as a comment to this post).  There is no tracking or approval workflow for changing the choices in a choice column.

• A list lookup can't be used as part of a formula in a calculated field. (from the Stump the Panel forum on End User SharePoint)

• A list lookup can't be accessed in "edit in datasheet" mode, which means that a look up value should probably not be a required field or there’s no possibility of a “bulk edit.”  (from Sue Hanley)

• A choice field won't maintain referential integrity if changed, and a lookup will (?)  (from Real World SharePoint Experiences by John Powell - I haven't tested this.)

• A list lookup will render the data in the field as a hyperlink, which users could click through to see the master list record (this may be good, bad, or neutral depending on your data) (from this thread on SharePoint University)

• A list lookup lets you add additional metadata fields about the list item (from Mark Miller on this thread on End User SharePoint)

• If looking up to a document library, the document name field is not available for lookup (from a comment on this thread on End User SharePoint)

• You can't filter or sort a lookup field so that the column displays the data in your desired order.  It orders by ID, so your choices can't display alphabetically.  One user on this thread on End User SharePoint (comment #57) says it is possible to install a custom field type "view filtered lookup" which will do this, but I have not tested this.  With a choice field in a site column, you can alphabetize the data or sort it whichever way you like.

To Note:

I checked the SharePoint Server 2007 Best Practices book by Ben Curry and Bill English, and it did not contain any additional information on the subject.

This question was posted to the Experts Exchange, but the approved answer bascially describes how to implement either of the two options, not much about potential gotchas.  Lame.

If you have any additional pros or cons on this subject, please leave a comment!

File downloaded from sharepoint document library replaces spaces in file name with underscores

I have been noticing for some time now, in several MOSS implementations, that spaces in filenames are replaced with underscores on file download/upload from SharePoint.  I was blaming this on SharePoint SP1, since I started to notice it around the time of that release, however this discussion on MSDN indicates Internet Explorer 7 is the reason.

To see the behavior, find any document in a SharePoint document library with spaces in the filename, or upload one.  Then download the document to your desktop - you can see that the underscores are added in the "Save As" window.

If you are working quickly and not expecting this filename change to happen, you would save the document to your desktop, make edits, and then re-upload it later.  Since you didn't actively change the filename, you would expect the document to save over the original in the document library.  This is the way SharePoint has traditionally worked.  But what you end up with is two copies of the document in the document library. 

 

Disclaimer - I'm sure we can all agree that the best practice in general is to check out / check in your document rather than downloading it to your desktop.  (The underscores are not added during checkin/checkout.)  But what if someone else has the document checked out, and you can't reach them to ask them to check it back in, and you're under pressure to make edits right away?  Or what if you thought you were just taking a copy, but the edits you make on your desktop turn out to be the preferred version?    Or what if you haven't fully tested the offline sync capabilities of MOSS 2007, and you want to be absolutely sure the document is accessible when you're offline?  These and many other real-world situations could lead to this downloaded-file scenario, which could lead to multiple copies of the same or similar documents in your SharePoint environment, which is exactly what most of us are trying to avoid. 

The MSDN thread proposes a workaround, although I will argue that the adding of underscores is not necessarily a bad thing, expecially since SharePoint can cause problems when working with filenames that include spaces.  I think it's important to be aware of this download behavior and to work toward minimizing the multiple-copies effect - emphasize checkin/checkout vs. download in end-user training sessions, for example.

Best Practice - do not use dash or hyphen in SharePoint system account / server farm account name

We recently saw an issue at a client site where the client chose to use a dash, or hyphen, in the name for the server farm account (a.k.a. the database access account, a.k.a. the System Account) - e.g. "moss-admin."  The account worked until our infrastructure expert tried to create the Shared Service Provider - it hung for over 10 minutes, and when he checked the event log he found it flooded with errors to the effect that the user could not be found in the domain.  Once they went back and changed the account name to remove the dash, they were able to create the SSP without any issues.  Going forward we are recommending that as a best practice, you should not use any special characters (e.g. \ / : * ? " < > | # { } % ~ & - _ . , ) in the server farm account name.