The Goldfish Bowl : SharePoint

MOSS receives DoD 5015.2 certification

grahamtyler — Tue, 29 May 2007 17:45:00 GMT

For those who have been building or evaluating records management solutions using Microsoft Office SharePoint Server 2007 (MOSS), you may be aware that MOSS was recently submitted to take the DoD 5015.2 certification test. Adam Harmetz explained why the DoD 5015.2 certification might be relevant for some customers in a post on the Records Management Team Blog a while ago.

Good news - it was just announced that MOSS has passed the test, and received DoD 5015.2 Certification. Hurrah! You can now see MOSS on the Joint Interoperability Test Command list of certified records management applications (meaning that it's official :-)). The capabilities will be made available via an add-on later this year.

The solution has been developed by using the supported MOSS object model - so in theory, anyone could have built the solution given enough time. I think that this is a good example of the power and capability of the solutions that can be created by building on the MOSS platform. Whilst Microsoft chose to address this particular US standard because it is widely recognised, hopefully this shows that MOSS-based solutions can be adapted to meet differing standards. For example, in Europe the upcoming MoReq2 standards look as though they will be increasingly important in the near future. I wonder whether there are any partners looking to build a similar 'compliance pack' for MoReq? (Just my speculation by the way :-)).

If you've not heard of DoD 5015.2 yet, or you do not have a specific need to be compliant with that standard, you probably don't need to think about installing the components.

[UPDATE 5th June 2007]: There is a great white paper that was published by the partner that developed the DoD 5015.2 certification solution for MOSS, describing the new functionality that will be added, here: Military Grade Compliance for SharePoint 2007 (published in January 2007).

There is also now a post about the certification by Adam Harmetz, ECM Program Manager on the ECM Team Blog here.

SharePoint dev team start blogging

grahamtyler — Fri, 13 Jan 2006 13:10:00 GMT

The SharePoint product development team at Microsoft have recently launched the SharePoint Team Blog, where they will be talking about the upcoming releases of the product set. Already published are posts from the Corporate VP of the Office Servers product group, and the General Manager of SharePoint Portal, Search, and Content Management, so make sure to subcribe!

'Windows Folder web part' published to GotDotNet

grahamtyler — Wed, 30 Nov 2005 03:06:00 GMT

I have just posted a sample SharePoint web part to GotDotNet (note: since moved to MSDN Code Gallery), which I've called the "Windows Folder web part". This is the result of a project I worked on some time ago which I'm now able to share.

What does it do?

The Windows Folder web part allows users to store files within a standard Windows (NTFS) folder in a shared network location and display a list of those files in a SharePoint page via a consistent ‘document library’-style interface.

This means that if your users need to work with file types that do not work well when stored within SharePoint, you can now continue to store them in NTFS, but users can locate them in SharePoint alongside the rest of their files that are stored within SharePoint, via a consistent interface. (Note that NTFS does not natively support all the SharePoint features such as check-in, check-out, version history etc so these options are not available for files accessed via the Windows Folder web part.)

The initial requirement for which I developed this solution was for a company which was migrating all user files from NTFS to SharePoint, but were heavy users of Microsoft Access, with hundreds of small databases stored in NTFS used for various adhoc custom purposes. They would often have multiple users reading and editing data from an Access database simultaneously. When accessed via SMB (i.e. over the local network), Access is capable of handling this type of 'simultaneous access' pretty seamlessly. However, if accessed via HTTP (such as if stored within SharePoint), due to the stateless nature of HTTP, each user perhaps unknowingly downloads a local copy of the database. Any editing they perform happens only on their local copy. If they even realise this, there is no easy way to synchronise their changes back to the version stored in SharePoint and resolve any conflicts. My solution - keep doing it the old way behind the scenes but pretend to store them in SharePoint :-). This way users still have a single place to go to find all their files.

I'm sure you can think of other scenarios where this could be useful. Note that even with this web part available, you should continue to store most file types within SharePoint to take advantage of check-in, check-out, version history and all the other benefits SharePoint adds over NTFS. Use this solution only when there is something blocking you from otherwise using SharePoint.

Sounds hard to manage?

This is the cool bit: When a SharePoint site administrator adds the Windows Folder web part to the site, a new NTFS sub-folder representing the site is automatically created underneath a 'root' NTFS shared folder (configured by the server administrator when first installing the web part). The NTFS security ACLs for each sub-folder are automatically synchronised to match the list of SharePoint users for the site, so the site administrator experience is simply to "drag and drop" the web part. New users added later to the SharePoint site will also be added to the NTFS folder next time the site admin visits the site.

Works best (most securely) if Kerberos authentication is used.

Where can I get it?

You can download the entire solution from ~~GotDotNet~~ the MSDN Code Gallery, including install files, source code and full documentation (hence I'm not going into great detail in this post as to how it works :-). Please note that the solution is only provided "as is", i.e. as a sample with no support provided, and I'd encourage you to evaluate it thoroughly and make any changes required before deploying into production to determine if it meets your needs and security requirements. If you review the source code you may find that you can improve it in some (possibly many ;-) ways - if so please go ahead - I'd welcome any feedback on the solution or advice on how it could be further improved! Hope that you find it useful. If you have any questions, please post them on the ~~GotDotNet~~ MSDN Code Gallery message board (or use the contact form on this blog).

[UPDATE: 3rd Sept 2007 - changed the hyperlinks from this article to point to a new download location after the GotDotNet CodeGallery was phased out - solution is now located in the GotDotNet User Samples area. Thanks to those who pointed out the original links no longer worked.]

[UPDATE: 22nd Feb 2008 - changed the links again after the whole of GotDotNet was shut down :-), code was migrated to the MSDN Code Gallery.]

SPS Administrator's Guide blocked by HTML Help security update

grahamtyler — Mon, 20 Jun 2005 07:43:00 GMT

You may find that the downloaded compiled help file (.chm) version of the SharePoint Portal Server Administrator’s Guide (found here on microsoft.com) will no longer open correctly after applying the latest batch of Windows XP security updates released last week on 14th June (http://www.microsoft.com/technet/security/Bulletin/MS05-026.mspx). This isn’t specific to the SPS admin guide, but potentially any downloaded .chm file (although the WSS admin guide seemed to work fine).

The solution is to right-click the .chm file, click Properties, and click “unblock”. The guide will then open correctly. See this support article for more details: http://support.microsoft.com/kb/902225

Might save a few minutes of head-scratching :-)