In Search of Document Control’s Holy Grail

Just over a year ago, our site was sold by its owners to another parent company. In the run-up to the sale, we had been slowly making ourselves a new intranet based around Microsoft SharePoint. After the event, SharePoint kicked off in a big way, with more and more projects and teams starting to use it for their file storage.

Fast forward to today, and our critical business data is split about half-and-half between SharePoint and the older “file store” (simply a Windows Server box with a giant, shared partition). The Powers that Be have decided that now is the time to do something about it, and standardise on one solution. What that solution is, however, is proving difficult to grasp.

SharePoint is now, in my opinion, past critical mass. The majority of Engineering use it for all their filing and often other activities. The rest of the company is split — maybe 50% use it, 50% don’t, and of those that don’t, half are distrusting or actively hostile.  The IT team have been enthusiastic adopters, but a number of technical issues remain unsolved, which has set them looking at alternatives.

As I see it:

  • SharePoint, first and foremost, features configuration control and revision history for documents. This is the stuff that software projects live by and die without, yet there are areas of the business that just don’t see the advantage. The ability to view the same data in many different ways by use of metadata means that every part of the business can have the view they want. It also offers a host of other features such as calendars and task lists that a number of projects are actively using, and full-text search takes milliseconds rather than days for a data set in the hundreds of gigabytes.
  • Network Shares are simple, and have essentially no learning curve. They’re also not as affected by proprietary software ‘lock-in’ — it’s far easier to get your data out of a network share than out of SharePoint should you need to. They also support larger files, and in our experience provide a faster access speed.
  • Subversion is most of our software teams’ source code management software. I once ran a project entirely out of Subversion — users liked the ability to merge Word document versions using Track Changes, but by and large the non-technical staff found it too complicated and difficult to use.
  • Alfresco and KnowledgeTree have been suggested as possible SharePoint equivalents that could be cheaper if we used their open source versions, but could also introduce a host of other problems.
  • Clearcase was suggested by a friend via Twitter, but it seems likely that as a primarily source code-oriented tool, the learning curve may be too steep for many users.

I’m interested to know how other companies solve the problem of document control (primarily of MS Office documents), and what tools they use. If you haven’t already waded in on Twitter or Facebook, feel free to do so here!

I’d like to believe that this is such a common problem that there is an existing, widely-used solution — but the more I talk to people about it, the less I am convinced that such a thing exists. Even if it doesn’t, what do you think is the least bad of all the options? Is there anything we haven’t considered?

Facefinder

Facefinder is a quick script I wrote in my lunch hour that makes a page of the names and faces of everyone I work with, to help new starters figure out who everyone is.

It comes in two varieties, a PHP script and an ASP page for Microsoft Office Sharepoint Services (MOSS) 2007.

I apologise profusely for the use of tables – I couldn’t find a way of rendering it nicely in both IE and Firefox/Chrome/etc. without them!

Using the PHP Script

  • Download the PHP version from GitHub.
  • Unzip the contents, and put them on a web server that can run PHP. (I’ve tested it on Apache and IIS with PHP 4.something.)
  • Add photos of everyone in the photos/ directory, in the “Firstname Lastname.ext” format. JPEG, GIF and PNG are supported. Ideally, crop them to a 300×300 square, but at least resize them to 300 by something. (If you need to batch resize, I recommend IrfanView for the job on Windows boxes.)
  • Navigate to http://yoursever/facefinder/index.php and see the result!

Using the MOSS 2007 page

  • Download the MOSS 2007 version from GitHub.
  • Unzip the contents, and put them in a document library on SharePoint.
  • Load the page in your web browser, and see the result!
  • If you don’t see anything, maybe SharePoint doesn’t have a proper list of users in it. On our intranet we pull the list from Active Directory as a nightly job; this is configurable somewhere within the Site Services admin panel.
  • If you see names but no pictures, none of the users has a picture set. On our intranet we get users to set their own pictures via their “My Site”, but if you don’t use “My Sites” you’ll have to find another way of getting them in.

Troubleshooting

I’ve never tried deploying these outside of our intranet, so for all I know it might fail completely for you. Hopefully it doesn’t, but if it does, leave a comment below or e-mail me and I’ll see if I can help you out.

An Ode to Sharepoint

At a loss for other, more pleasant subjects to blog about, I will instead write about my nemesis, that being that has brought naught but pain to my life. I speak, of course, of Microsoft Sharepoint.

To upgrade one’s version of Windows — Vista to 7, say — is by and large a pretty painless experience for the home user. Office, likewise — there’s no dread that your Office 2003 files will be completely unopenable in Office 2007. So why is the poor sysadmin not afforded the same easy upgrade path?

In order to move an existing SharePoint Services 2 website to a new network with Microsoft Office Sharepoint Services 2007, one must:

  1. Learn more than is healthy about the workings of Sharepoint and IIS (2 days, d10 SAN)
  2. Back up the original site to disk (using stsadm.exe not smigrate.exe, as the latter is broken) (5 hours, 13 GB)
  3. Install Windows Server, IIS, SQL Server and Sharepoint Services 2 on a new machine (1 hour)
  4. Configure said IIS, SQL and Sharepoint (1 hour)
  5. Restore the Sharepoint site from disk onto the new machine (>8 hours, >120 GB, d10 SAN, fails unrecoverably when out of disk space)
  6. Perform an in-place upgrade to Sharepoint Services 3 (Several hours, 40 GB, may fail unrecoverably)
  7. Back up this site to disk (5 hours, 15 GB)
  8. Configure MOSS 2007 on the destination server (2 hours, 24 Google searches, d10 SAN)
  9. Restore the disk backup to the MOSS 2007 server (5 hours, 40 GB, may fail right at the end if previous step performed incorrectly, d100 SAN if this occurs).
  10. Manually recreate permissions on every Sharepoint site since all the users are now part of a new domain (8 hours, d10 SAN)
  11. Perform a ritual to offer Great Cthulhu the souls of Microsoft’s Sharepoint development team (d30 SAN, remarkably quick by comparison)

I began this task on Tuesday afternoon as a mildly knowledgeable Sharepoint user with virtually no admin experience. By Thursday afternoon, I may have been our company’s most experienced Sharepoint-wrangler. On Friday morning, I started the above procedure. We are now on Step 5. 200 people are expecting to have Sharepoint access tomorrow. They have not a snowball’s chance in R’yleh.