Microsoft Enterprise Content Management (ECM) Team Blog

CMIS Management Interoperability Services (CMIS) – Public Review of Version 1.0 begins

2009-11-09T05:46:00Z

Around two-and-a-half years ago (at the AIIM conference in Philadelphia in May of 2006), my counterparts at IBM and EMC and I started discussing the need to form a group to create an open services standard for interacting with Enterprise Content Management systems (like SharePoint, IBM FileNet P8, EMC Documentum, etc.) in a uniform way. An earlier blog post explained the full rationale – but in short many customers and partners made it apparent that having to create one-off "connectors" between each application (like eDiscovery applications, Portals or Business Process Management systems) and ECM system was making it hard for customers to use more than one ECM system and for partners to build great applications that could "just work" with whatever systems a customer is using.

And now, after working with many other vendors like Alfresco, Nuxeo, OpenText, Oracle, SAP, and others on the CMIS specification, forming a Technical Committee at OASIS to deliver that specification as a truly open standard, and having four "plug-fest" events where we've tested actual (prototype) implementations of the spec together to make sure it would work in the real-world – I'm thrilled to announce that on October 23, 2009 Version 1.0 of the CMIS specification entered OASIS' public review process.

"Public Review" -- What does that mean?

Those of you who aren't familiar with the mechanics of the OASIS standards process (i.e. nearly everyone) are probably wondering what "public review" means, and how it relates to everyone's ultimate goal of having a final 1.0 specification available so that everyone can start supporting CMIS in their applications. (If you want the full details of how the Public Review Process works, you can read OASIS official "Technical Committee Process" rules – but the summary below is a bit more self-contained and user-friendly).

Public Review is one of the final stages of the OASIS standardization process –it means that the members of the Technical Committee think the spec is (almost completely) done, and that we're soliciting feedback from the general public about what changes (if any) they'd like to see in the
specification before it becomes the final CMIS 1.0 standard. The public review period lasts for 2 months – so it will continue until December 22, 2009.

Anyone can look at the spec and send us comments–I've also copied the full public review announcement below for reference.

The Technical Committee is then required to review and respond to all comments – which could include updating the specification, or responding to those comments without making a change (which we would likely do if the comment is asking for new features or big enough that it would be better deferred to a future version of the specification). If those comments result in substantive changes, then the updated spec would undergo a shorter (15-day) additional round of public review. If not, then the Technical Committee will submit the CMIS 1.0 specification (possibly with some minor clarification updates) for a final approval vote by the OASIS membership – a process which takes about a month.

Once the final OASIS approval vote is closed (assuming of course that CMIS gets sufficient votes to pass), CMIS 1.0 is (finally) an OASIS standard!

OK... so when will CMIS 1.0 be final?

Those of you keeping count from the above paragraph already figured this out – but CMIS is on track to become a final 1.0 standard sometime in the first 3 months of 2010 (exactly how soon will depend on the volume of comments we get in Public Review and the changes required to address them).

Given all of the work that the Technical Committee has done in writing & testing the spec so far, we aren't expecting to make many (if any) substantive changes – but of course if there are any issues in the spec that will hamper it’s real-world adoptability we want to hear about and address those now in Public Review, rather than waiting until the 1.0 standard is final (when making changes will require a whole new version of the specification.) So please do review the spec and give us your feedback!

When can I expect vendors (including Microsoft) to start supporting CMIS in their products?

At this point, pretty much every vendor in the ECM space is really motivated to start supporting CMIS in their respective products. We've all seen the excitement from customers about CMIS -- for example, a recent AIIM survey showed that 15% of organizations are already interested in using CMIS. (This is an unbelievable number for a standard that isn’t even final yet!)

Of course, the prerequisite for all this is a final, OASIS-ratified 1.0 standard. While several companies have released prototypes based on interim drafts (which are wonderful proof-points that CMIS is ready for real-world implementation), look for vendors to start disclosing specific plans once the specification is final.

For Microsoft's part, we announced at the ARMA 2009 Conference and at our own SharePoint Conference in the last two weeks that we are planning to deliver support for CMIS within SharePoint 2010.

Since that announcement we've gotten lots of requests for additional details ("give me an exact date!", "tell me exactly what functionality will be included", etc.) I wish that this blog post could be the place to provide more detail – but it's simply not possible at this time. Here's why -- those of you who attended the SharePoint Conference last week have seen that SharePoint 2010 is looking pretty shiny and polished. But until the CMIS 1.0 specification is final, we can't realistically commit to exact dates when our CMIS support would be ready. This means that our plans need to be flexible to balance the following needs:

Not rushing the finalization of the CMIS 1.0 specification in a way that would compromise its quality
Release CMIS support as soon as possible for SharePoint 2010 that meets the interoperability needs of our customers and partners

We're definitely looking forward to having the CMIS standardization process complete so we can lock-down our plans to the point where we can share additional details. Please stay tuned for more information.

Ethan Gur-esh,
Program Manager
CMIS Specification Editor
CMIS Technical Committee Secretary

Copy of the OASIS Public Review Announcement:

To OASIS members, Public Announce Lists:

The OASIS Content Management Interoperability Services (CMIS) TC has
recently approved the following specification as a Committee Draft and
approved the package for public review:

Content Management Interoperability Services (CMIS) Version 1.0

The public review starts today, 23 October 2009, and ends 22 December
2009. This is an open invitation to comment. We strongly encourage
feedback from potential users, developers and others, whether OASIS
members or not, for the sake of improving the interoperability and
quality of OASIS work. Please feel free to distribute this
announcement within your organization and to other appropriate mail
lists.

More non-normative information about the specification and the
technical committee may be found at the public home page of the TC at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis.
Comments may be submitted to the TC by any person through the use of
the OASIS TC Comment Facility which can be located via the button
marked "Send A Comment" at the top of that page, or directly at:
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=cmis.

Submitted comments (for this work as well as other works of that TC)
are publicly archived and can be viewed at:
http://lists.oasis-open.org/archives/cmis-comment/. All comments
submitted to OASIS are subject to the OASIS Feedback License, which
ensures that the feedback you provide carries the same obligations at
least as the obligations of the TC members.

The specification document and related files are available here:

Editable Source:
http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.doc
PDF:
http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.pdf
HTML:
http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.html

Schema:
http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/CMIS-Core.xsd
http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/CMIS-Messaging.xsd
http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/CMIS-RestAtom.xsd

OASIS and the CMIS TC welcome your comments.

Mary P McRae
Director, Technical Committee Administration
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
twitter: fiberartisan #oasisopen
phone: 1.603.232.9090

Publishing Sites: Field Controls or Web Parts... That is the Question!

2008-10-09T07:40:00Z

There isn't a week that goes by where I don't get an email asking me this very question. More often than not, its because someone has been using the Content Editor Web Part (CEWP) when they should have been using the Publishing HTML field type. This mistake typically goes unnoticed until a customer needs to roll back to a previous version of a page or when they run a content deployment job. So what goes wrong? Well, the CEWP doesn't store version history, it doesn't participate in any publishing approval workflow and it does store absolute URLs rather than relative URLs. The first problem means you'll have to go to site backups to get access to previous versions of content, the second problem means that users will see updates to the content in the CEWP even if an editor hasn't approved the page for publishing and the third problem means that all your hyperlinks will resolve to the wrong address (e.g. http://staging.adventure-works.com/ vs http://www.adventure-works.com/).

Thankfully, all of these problems can be avoided by using the Publishing HTML field type. I've talked at length with Andrew Connell (MVP) about this and I know it's something he is passionate about so I asked him to write up a guest post to explore the topic.

Ryan Duguid
Technical Product Manager
Microsoft Corp

Andrew Connell on Field Controls and Web Parts

One of the most common problems I see with people developing Publishing sites stems from the lack of understanding in the core differences between Web Parts & Field Controls and when to use them. Many a consultant have dug a deep hole in this area. My goal in this post is to make you aware of the differences to make educated decisions when selecting one over the other.

What follows is a discussion with respect to MOSS 2007 Publishing sites (aka: WCM sites), but all the concepts apply to any Windows SharePoint Services 3.0 based site.

When creating editable content regions on a page layout, enabling content owners to add and manage their own content, developers/designers are presented with two options: field controls or Web Parts. These two options are very different and Publishing site developers should be aware of the differences. The fundamental difference comes down to where the data is stored.

Web Parts
Web Parts come straight from ASP.NET and their data is stored in a personalization store. Microsoft was nice and baked the personalization store into the site collection's content database. Data in a Web Part is stored within the context of the PAGE (i.e.: URL) & the user (which could be the shared user or a specific person). This does allow the content in Web Parts to be uniquely personalized by authenticated users.

In addition, developers and designers can only create Web Part Zones on the page layout. Content owners can then put any Web Part in the zones and any content within them.

Field Controls
Field Controls are much different from Web Parts. They are more like windows into list items. A field control pulls data (in display mode) from a particular column in a list item and writes back to that column in edit mode. Pages in a Publishing site are stored as items in a list; the Pages list. Because they are in a list, they can leverage all the benefits a list has to provide, but visioning & history is the most important here. Just keep one thing in mind: field controls are simply gateways, or windows, to the data.

When a developer places a field control on a page layout, they have the ultimate control of where it is placed on the page and any rules such as if the content owners can insert tables or images into the content. The content owners can only work within the rules defined by the developers.

What is the significance?
Great question! From my experience, MOST customers (90%+) who are rolling out a Publishing site, or Web-based content management systems such as MOSS 2007 WCM, are doing so because the following aspects are important to the project:

Consistent lookand feel (aka: a corporate brand)
Empower content owners & subject matter experts (SME) to maintain the content
Free up IT staff from updating content submitted by SMEs
Structured organization of contentand a versioned and/or historical record of the content

The challenge here is that Web Parts pose a problem with this approach. Because their data is stored in the ASP.NET personalization store in the context of the page (it's URL mind you) & the user. However with field controls, the data is saved with the page's list item. This means that when the page is updated, a new version is created and the old data is retained with the page.

Another challenge is with URLs in the content... especially relative URLs. Take the Publishing HTML field type & the Content Editor Web Part (CEWP). The CEWP does not store relative URLs... it stores only absolute URLs. Even if you enter a relative URL into the editor, it will be converted to an absolute URL. The rich text editor that the Publishing HTML field type is tied to does not convert relative URLs to absolute URLs.

If structure and history is important on your site, you should ONLY consider field controls for your content. If you want to have a more relaxed authoring environment where structure & history isn't important, Web Parts are better. What if structure & history is important... does it ever make sense to use Web Parts? Sure! Use them for providing functionality like stock quotes, consuming news feeds, or rolling up content (as in the Content Query Web Part). In this scenario, the only data that's stored is configuration data... not true content.

To summarize: the content in Web Parts is not versioned and there is no history, but the content in field controls is versioned & a history is retained (provided the Pages library has versioning enabled, which it does by default).

-AC

Andrew Connell
MVP Office SharePoint Server
www.andrewconnell.com/blog
Sr. SharePoint Instructor - Ted Pattison Group
http://www.tedpattison.net/

Announcing the Content Management Interoperability Services (CMIS) specification

2008-09-09T23:22:00Z

Today, we're excited to announce the launch of a standards effort for Enterprise Content Management systems that Microsoft has been driving with several other major vendors (IBM, EMC, Alfresco, OpenText, SAP, Oracle) called "Content Management Interoperability Services" (or CMIS, for short).

The goal of CMIS is to define a web services standard for interacting with Enterprise Content Management systems like Microsoft Office SharePoint Server, EMC Documentum, IBM FileNet P8, etc.

Why: Integrating multiple ECM systems is hard

We've heard from many organizations that want to use SharePoint, but have other ECM systems or applications in place that they need SharePoint to work with. Often these deployments are the result of different business units that deployed different ECM systems or that were "inherited" from mergers or acquisitions, or the organization may be transitioning from one ECM system to another over time.

Having multiple ECM systems introduces integration challenges: Enterprises (rightly) want their users to be able to access and manage all content in the way that best meets their needs, regardless of which system it actually live in. For example, users want unified access to all the content they need to work with on their team site, organizations want their electronic discovery applications be able to find content and suspend its disposition across any ECM system. But in practice integrating these ECM systems is a challenge because each has its own interfaces. Even though many capabilities in each system are fundamentally similar (e.g. most ECM systems have a notion of "check in/out" & version history, and of different Content Types), and most systems' interfaces are "open" for anyone to integrate with, tying them together requires integration "connections" for every link between systems. (For example, Microsoft Search Server and Office SharePoint Server support an open "connector" model for indexing content stored in other systems - and Microsoft even provides connectors for some common ECM systems like EMC's Documentum and IBM FileNet).

This connector approach generally suffers from a few limitations:

1) Each link between systems requires a different "connection": For example, the Enterprise Search connector for IBM FileNet is different than the one for EMC Documentum, and neither one would help an organization that wants to use an IBM or EMC Search product to index content stored in SharePoint.
2) Connections tend to be "special purpose": Because today each point of integration requires additional work, most integration connectors tend to be very specifically-focused on particular scenarios. For example, while the Enterprise Search "connectors" enable Microsoft Search products to index content stored in a Documentum or FileNet system, customers who also want to browse their Documentum or FileNet content on the home page of their SharePoint portal will need to use a separate kind of connector for that (probably a Web Part).

So while today integration is technically possible, it's not as simple as it could be.

To truly make it simple for ECM systems to interoperate, we need a standard set of ECM interoperability interfaces - that way, every system could support the same interfaces and they could work together without the need for special purpose "connectors" between each pair of systems. And that's exactly what the CMIS standards effort attempts to define.

What does the CMIS specification define?

The CMIS specification defines a standard "domain model" for an ECM system - a set of core concepts that all modern ECM systems have, like Object Types (which in SharePoint we call "Content Types"), properties, folders, documents, versions, and relationships - and the set of operations that can be performed on those concepts, like navigating through a folder hierarchy, updating a document, etc.

The specification does NOT try to include all the capabilities of an ECM system - because many of these are simply too different between ECM systems. But the specification does attempt to include the fundamental concepts that are (a) relatively common across current ECM systems, and (b) enable the common integration scenarios that we've heard from customers to date.

The specification then defines how to bind the CMIS "domain model" to two different web service protocols: SOAP (Simple Object Access Protocol), the web services protocol used by many ECM systems (including SharePoint), and Atom, a newer web services model used in many "Web 2.0" applications.

You can download a preview copy of the specification here.

Who else is involved in the CMIS effort, and how long has it been going on?

Of course, this isn't a new problem, and it's not one that any one company can solve on their own. So back in 2006 Microsoft started working with IBM and EMC on the CMIS effort - since all of our organizations realized the need to enable better interoperability between our systems. Since then we've expanded the effort to include several other organizations: Alfresco, Oracle, OpenText, and SAP.

Over the last two years, this group has worked together to create and refine the specification, including validating it using actual prototype code that each company wrote on top of our products.

What's next for the CMIS specification?

The next step for the CMIS specification to become an open standard that all ECM systems can implement to facilitate interoperability is to transition its development into a public standards organization - and that's the step we're taking today. We're submitting the CMIS specification to a new CMIS Technical Committee being formed in the OASIS consortium, so that all interested parties can join the effort and continue to refine the specification into a final "1.0" version. (Click here to learn more about joining OASIS Technical Committees). We anticipate that it will take around 1 year for the OASIS Technical Committee to complete work on the final 1.0 version... but from this point onward, the exact schedule will be determined by the committee.

When will Microsoft include support for CMIS into SharePoint (or other products)?

Of course, Microsoft's goal (which is shared by all of the companies participating in the CMIS effort) is for the CMIS specification is to become the interoperability standard that we can incorporate into our products to reduce the complexity of managing & integrating multiple ECM systems... and today's announcement is an important step in that process.

As the specification goes through the OASIS Technical Committee process and approaches a final 1.0 version, we'll provide more information on when and how you'll see support for CMIS for SharePoint and other Microsoft products.

Ethan Gur-esh, Program Manager.

New blog: To The SharePoint

2008-07-29T23:12:00Z

The SharePoint IT Pro Documentation team has launched a new blog. This is a great place to find out about new and upcoming SharePoint documentation and provide your feedback. Check it out here: To the SharePoint.

Content Deployment and the Infrastructure Update

2008-07-15T19:56:00Z

On the 20th May, we released two hotfix packages focused on Content Deployment. These packages delivered performance improvements and addressed a number of known customer pain points. The hotfixes have been rolled in to the Infrastructure Update for Office Servers that was released today so if you've been experiencing issues with Content Deployment, download the pack, install it and you'll get federated search thrown in with the deal.

The updates can be downloaded from the links below:

Infrastructure Update for Microsoft Office Servers (KB951297) - x86
Infrastructure Update for Microsoft Office Servers (KB951297) - x64
Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) - x86
Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) - x64
Infrastructure Update for Microsoft Office Project 2007 (KB951547) - x86

Installation Instructions are available from the links below:

Deploy Software Updates for Windows SharePoint Services 3.0
Deploy Software Updates for Office SharePoint Server 2007 - This article also applies to Project Server 2007, SharePoint Server 2007, Search Server 2008 and Search Server 2008 Express.
Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007) (This article will go live later today)
Install the Infrastructure Update for Microsoft Office Servers (Search Server 2008) (This article will go live later today)

While you are installing the Infrastructure Update, I'd recommend you have a read of the following blog posts on Content Deployment:

SharePoint ECM Team Blog on "End to End Content Deployment Walkthrough"
Stefan Goßner's "Deep Dive into the SharePoint Content Deployment and Migration API"
Spencer Harbar's "Ensure your platform hygiene..."

Here is a summary of the Content Deployment issues addressed in the Infrastructure Update:

Incremental bug fixes:

Incremental import can fail if a feature with a custom content type has been reactivated on the destination.
Unpublished pages do not get unpublished on the destination.
Reinheriting permissions on the source does not propagate incrementally.
Deleting a permission level on the source causes a "Permission level cannot be found." exception during incremental import.
Incremental behavior with the Recycle Bin improved. Incremental import fails with a "FatalError: You cannot perform this action on a checked out document." exception.
"Violation of PRIMARY KEY constraint" error during export.
Document "Title" field does not get deployed by incremental deployment in some cases.
In some cases, making permissions changes on the source or destination will result in a "The specified name is already in use." error.
Deleting or renaming an item then creating one with the same name causes incremental deployment to fail.
Incremental deployment fails when pages have independent permission settings.
Deleting a file and folder can cause incremental deployment to fail in some cases.

Other bug fixes:

Removing a User from a group does not propagate to the destination during incremental deployment.
Some source web settings related to search are not propagated to the destination.
Content Deployment can time out incorrectly on large deployment jobs.
Miscellaneous SQL deadlocks.
Quick deployment jobs behave incorrectly when Variations is used.
Quick deployment fails when pages are Quick Deployed while the Quick Deploy job is running.
Running One-time jobs manually can fail.
In some cases, a content deployment job can get stuck in a "Preparing" state forever.
Deployment sometimes unghosts items that are ghosted on the source.
Custom master page settings on the source are not propagated to the destination during deployment.
Content deployment fails when compression is disabled.

If you want more details on the Content Deployment issues addressed in the Infrastructure Update, visit the Microsoft Help and Support site:

WSS: http://support.microsoft.com/kb/952698/
MOSS: http://support.microsoft.com/kb/952704/

Ryan Duguid
Technical Product Manager
Microsoft Corp

Announcing: End-to-End Content Deployment Walkthrough

2008-06-11T22:45:00Z

Hi, I'm Cern McAtee, a technical writer for Office SharePoint Server 2007. I'm pleased to announce that the Office SharePoint Server 2007 content team and the Global Readiness team have combined efforts to write and publish a new walkthrough guide for content deployment: End-to-End Content Deployment Walkthrough.

What's covered

This downloadable guide is aimed at IT pros planning to use content deployment with their enterprise sites using Microsoft Office SharePoint Server 2007. The guide takes you through the steps for setting up source and destination site collections, creating a deployment path and job, and then running the job to see how it populates the destination site collection with the content from the source site collection. One important thing to note when it comes to doing content deployment is that when you first set it up, the destination site collection must be empty. You can create the destination site collection using either the Blank site template, or by using the Stsadm createsite operation to create an empty site.

In addition to the walkthrough, we have also published a set of topics about Administering Web content management that cover publishing and content deployment operations. These topics are intended for IT pros who manage publishing and content deployment for their enterprise sites. More WCM topics that cover cache settings and profiles, document conversion, and variations will be published soon.

Send your feedback

We're very excited about publishing this walkthrough guide and the new WCM content, and we're especially interested in your feedback on this new content. There are three ways you can provide feedback on this content: First, in each topic you will find a "Click to Rate and Give Feedback" control with a text box for supplying feedback. Second, you can send us mail at o12ITdx at Microsoft.com. Third, you can use the "Leave a Comment" interface in this blog to provide comments, either about this blog entry or about the newly published content.

We look forward to hearing from you and to continuing to improve this content in partnership with you!

Thanks,

Cern McAtee
SharePoint Enterprise Solutions content team

Announcing: Administering Records Management in Office SharePoint Server 2007

2008-06-07T02:08:00Z

Hi, my name is Claudia Lake. I am a technical writer on the SharePoint Enterprise Solutions content team. In response to feedback from users, we have created Administering Records Management, which is a new set of IT Pro documentation on TechNet about records management in Office SharePoint Server 2007.

What’s covered?

In addition to providing information about how to create a Records Center site, the new records management administration documentation covers the following areas:

· Configuring an active document site for records management

· Configuring an Exchange Server 2007 e-mail server to send records to a Records Center site

· Managing holds

· Monitoring the Records Center site

Our intention is to provide you with all of the information you need to successfully set up, configure, and administer a Records Center site in Office SharePoint Server 2007.

Feedback welcome!

Have you ever wished you could have a say in the way documentation is written here at Microsoft? Well, now’s your chance. We welcome your feedback on the new Administering Records Management documentation and will do our best to make the improvements you suggest. What would we like to know? We’d like to know things like: Is this content useful? Is it detailed enough? Did we leave something out that you feel would be helpful? Did we include something that you feel has no value? We’re also interested in hearing what you like about this content so we can keep doing it. Anything you feel we should know about the Administering Records Management content is very important to us. Let us know what you think!

There are three ways that you can provide feedback about the Administering Records Management documentation:

1. The upper-right corner of each page has a Click to Rate and Give Feedback section. Click a star to rate the page and optionally provide feedback.

2. You can e-mail us at o12itdx at Microsoft.com.

3. You can use the “Leave a Comment” feature in this blog to provide comments, either about this blog post or about the Administering Records Management content.

We look forward to hearing from you and to working with you to make our content the best it can be.

Sincerely,

Claudia Lake

SharePoint Enterprise Solutions content team

Building a news workbench on MOSS 2007 -- Part 5

2008-05-10T01:12:00Z

[Part 1] [Part 2] [Part 3] [Part 4]

Greetings and welcome to the fifth and final post in this series describing the news management and delivery service we built on Microsoft Office SharePoint Server 2007 for our internal employee communication portal, Microsoft Web (MSW). I wanted to wrap up this overview by talking generally about our approach, how things are going, some challenges we had, and what's next.

How it's Going

Generally, we (and the MSW business team!) have been very happy with how the overall solution worked-out. We were able to address a number of challenges and short-comings with how publishing was done previously and streamline or eliminate many of the daily manual activities. Since the solution was built on pre-RTM bits a lot of our design decisions were made based on what we knew about the product at the time. There was definitely a lot of trial-and-error and leaning on members of the product team in the absence of documentation.

As I stated in my first post, it was our goal to use and showcase as many of the new features as possible. To take advantage of these features really requires understanding your content and how MOSS handles it. Depending on how your content is created, where it is stored, and how it needs to be made available may require content organization or business process changes. Centralizing content under consistent content type definitions makes subsequent organization, tagging, and data roll-up easier. Library support for multiple content types - and CQWP querying on content type - permits reducing the number of libraries required to store a lot of content. Content moderation, coupled with workflow and expiration policies makes it easier to create, update, and remove content in a more controlled and automated fashion. We have been able to take advantage of all of these features and gain many benefits, but it has required business to change their processes, too. Sometimes these changes are difficult, but where it can help standardize (and streamline) the publishing steps it has been worth it.

I would also add that our solution approaches content management in a specific way, but this is really a broad problem space that can be tackled many ways. That said, since developing the solution we have worked with several other teams and despite their different needs, they all boil down to understanding the content up-front and understanding MOSS2007 publishing features to inform content design and inevitable business process changes.

A Few Challenges

While we made lots of improvements to our publishing process with the new features, there remain aspects that still aren't as easy as they could be - and in some cases, required us to develop custom components. Data import to a SharePoint list is challenging and not easy to automate, which is why we had to develop the custom feed import application. Our service is flexible enough to support a variety of consumers (currently this tool can consume from XML or databases), but not without configuration work and coordination with operations when changes are required. Ideally, this would be an easier step in the cycle.

Search services have been greatly improved in MOSS 2007, but to support our editor's content discovery needs we really needed a richer query interface. We launched with the out-of-box advanced search, but the UI has limited sorting options, doesn't support nested queries, and the UI can't display the property's values. Our custom search solution builds on the OM and addresses these requirements. We have since made other improvements to this extended search solution and plan to make the binaries available to the community in the future.

As I previously described, moving data between the raw source list and the tagged candidate list uses a custom action, but we'd prefer to have a configurable workflow here instead. Also, because SharePoint lists are flat this candidate list requires several duplicate tagging fields for each newsletter - and with fourteen newsletters currently being published, the list is a bit unwieldy.

We are huge fans of the Content Query Web Part as a delivery mechanism and use it extensively in this solution and in variety of other content scenarios. However, the web part is pretty limited in the results it can show without additional configuration of its advanced web part properties (see the MSDN topic on Content Query custom properties). Consequently, we have extended the web part to expose some of these more common properties and even enable it to filter content dynamically based on query string parameters. This source code is available on CodePlex for your use: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=sptoolbox&ReleaseId=11150

The delivery of content stored in SharePoint really favors RSS - and while this is a great improvement, one which we take advantage of for most of our content delivery - there remains strong business need to email a HTML-formatted newsletter to a list of subscribers. As I explained in my last post, we ended up building custom solutions to address this requirement and outside of some on-going formatting challenges between IE and Outlook they have both worked pretty well.

What's Next

Since our initial release we have learned a lot more about the product and, working with other teams, gathered additional requirements. We have continued to make improvements to many of the specific custom components mentioned above, primarily around making them more extensible or easier to configure, but we also want to look at the design as a whole and see how we can streamline it even more.

One aspect that our solution doesn't take enough advantage of is workflow. We'd like to extend our use of this feature to make content moves, updates and even editorial notifications more seamless. We'd also like to extend this use into a richer information management policy. Currently, we just have basic item expiration on the news lists, but we'd like to enrich this step with user input and a better item archiving story. A few other areas we're kicking around for future enhancements include more flexible newsletter templates (perhaps ones that support offline or client authoring), better content auditing and reporting, and ways to retain history of dynamic pages.

Well, that's it for now. I hope you found this information useful and it aids you in your own efforts. We'll keep the community apprised of components we roll-out to CodePlex and continue to share news on our projects. Until next time!

Building a news workbench on MOSS 2007 -- Part 4

2008-03-29T03:52:00Z

[Part 1] [Part 2] [Part 3]

Hello again! Sean Squires here. This is part 4 of my series about the news management and delivery service we built on Microsoft Office SharePoint Server 2007 for our internal employee communication portal, Microsoft Web (MSW). I wrapped up the last post talking briefly about how we enable email delivery of edited news items, using a custom web part we built to package and format a select sub-set of list records. I want to continue describing the delivery process, explaining how we also use the Content Query Web Part to deliver this same content to portal pages and mention some changes we've made to the email delivery solution since the initial deployment in 2006.

Step 5: Content Delivery - Portal (using the CQWP)

We were big fans of the Content Query Web Part early on, realizing that it would provide a lot of relief for many of our content roll-up scenarios. By centralizing our news content and providing appropriate targeting fields, we could configure the web part queries to display different news items based on the values for these fields. Then, instead of editing sets of items each day or touching and re-publishing a lot of pages, editors could focus on just that day's news and the rolling off of content would take care of itself. This was an important consideration as most news stories published to the portal have a life of several days, first as a top or current story, and then as an archived story for two weeks.

Here is a screenshot of how the Content Query Web Part is used just on the MSW home page:

Each of these web parts have a query configured to only display one or a few items based on specific values in the target filter fields. For example, the lead story at the top of the page uses two filters, the DispCBQ value of "Home Page" to specify that it is the active top story, and the Home Page value of "Top Story" to indicate that it is a top story (as opposed to a related story, which surfaces in the Content Query Web Part right below). The web part is also set to sort by the Modified field in descending order and is limited to display only one item.

While we initially planned to just have the editors check out the target page and preview their new items from the page, we wanted to provide a similar experience to the email preview described last time, so we created preview pages of the two main targets - Home page and News landing page - and ensured that the target logic of the PublishedNews list schema supported three states: Preview, Published, and Archived. So the preview pages each had CBQs configured to display items that had been tagged as candidates, but not yet "published":

These pages mimic the production ones:

Once the editor is happy with the display, we provide a custom update action web part on these preview pages, designed to clear the Targets field and update the DispCBQ and PublishedIn fields for those tagged items in the list. Our future plans are to replace this rigid custom component with a more flexible action associated with a workflow.

Content Archiving

When a new item is "published" we don't just replace the story with a new one and rely on the sorting to act as our filter, we also clear the current story's DispCBQ value. We are then able to provide Content Query Web Parts on the archive pages which are configured to only display those stories where the DispCBQ value is false or where the PublishedIn value has a specific newsletter value:

In all of our newsletter archive pages, like the one above, we use the QueryOverride property of the Content Query Web Part to pass in something like:

<![CDATA[<OrderBy><FieldRef Name="ArticlePublishDate" Ascending="FALSE" /></OrderBy><Where><And><And><Geq><FieldRef ID="{b34d0f98-7f33-4e63-98ff-b69b5006f3eb}" Nullable="True" Type="DateTime"/><Value Type="DateTime"><Today OffsetDays="-14"/></Value></Geq><Eq><FieldRef ID="{f76a0dfa-4847-4e51-a334-10cbd9af7a86}" Nullable="True" Type="MultiChoice"/><Value Type="Text">Daily Newswire</Value></Eq></And><Eq><FieldRef Name="ContentType" Type="Text" /><Value Type="Text">Published News Item</Value></Eq></And></Where>]]>

We took this approach because we wanted to create a query whose results were updated based on when it was viewed. The CBQ property pane supports passing in the current day as a filter, but it doesn't support any offsets. Essentially, what this query is saying is get those news items in reverse chronological order by ArticlePublishDate for the last fourteen days where the PublishedIn value is equal to "Daily Newswire".

For more detail on using this and other key CBQ properties check out the MSDN article: How to Customize the Content Query Web Part by using Custom Properties (http://msdn2.microsoft.com/en-us/library/aa981241.aspx).

Here is a summary of the field logic we use to define the different "publishing states" of a selected news item:

	Targets	DispCBQ	PublishedIn
Preview/Selected	TRUE
Published/Delivered		TRUE	TRUE
Archived			TRUE

Step 5: Content Delivery - External

I mentioned briefly in my last post how we created a custom web part to package and deliver via email news items tagged for specific newsletters. While this solution has certainly worked out fine for us, it doesn't provide much design or content flexibility for our editors; it uses a template stored in the control templates directory of the file system and it supports only one template reference. So, all email newsletters sent out look the same and display the same data elements.

In order to better support a variable design model - and frankly, make better use of the page publishing features of SharePoint - we created a replacement solution in the summer of 2007. This new approach uses some of the same ideas behind the original mailer web part, but extends the concept by mail-enabling any page for email delivery. We did this by creating custom marker web parts that can be dropped on the page or baked into a layout to designate the start and end points for email content. A third web part is used to scrape and format the HTML within these markers and send the contents to the users/lists designated in the web part properties:

This approach effectively allow us to build a newsletter page composed of dynamic data displayed via a Content Query Web Part as well as content stored directly in HTML field controls and make it available for email delivery. Now instead of all the site newsletters being pushed through a single web part and having the same look and feel, they can be managed as pages and configured with different layouts and data elements. We recycled a lot of the old mailer web part design, but added preview functionality and the ability to track send jobs for troubleshooting purposes:

The biggest hurdle we ran into with this redesign - and continue to run into as we extend the new solution to other publishing projects - is the HTML rendering differences between Outlook and IE. Specifically, Outlook 2007 uses the Word 2007 engine for parsing and rendering HTML so you may have some nifty CSS styles on your portal that IE renders just fine, but not so nicely in the email client. Our approach here has been to generate the newsletter from a mirrored page so we can inject header and footer content we may not want to display on the portal page and override the site styles with ones that are more appropriate for Outlook. For more information on this subject check out the following articles: Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2): http://msdn2.microsoft.com/en-us/library/aa338201.aspx and Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2): http://msdn2.microsoft.com/en-us/library/aa338200.aspx

What about RSS?

Our discussion of content delivery channels wouldn't be complete without acknowledging Really Simple Syndication (RSS). We also make this option available by taking advantage of the Content Query Web Part's native ability to emit a RSS feed of the query results. However, because our editors wanted more flexibility on the display and placement of the RSS subscription button, for most of our newsletters we configure a CBQ on a hidden page, select the enable feed box to display the RSS feed icon, and then reference this URL on other pages, such as in a HTML field control. Here is a snippet of our newsletter subscription page:

Next Time

Well, that wraps up this post and my overview of the key components comprising our news management and delivery solution. I'll conclude this series in a final post talking about some of the lessons learned and future plans we have for our solution. See you then.

Announcing: Design and build sites for Office SharePoint Server 2007

2008-03-12T07:21:00Z

[Updated March 11, 2008: Based on your feedback, we have created a downloadable version of this guide. It's the same content, but now available in a convenient .doc format.]

Hello, ECM Team Blog readers. My name is Rob Silver. I'm a technical writer working on the IT Pro content team for Office SharePoint Server 2007. I'm excited to announce that the Office SharePoint Server 2007 content teams for the IT pro, developer, and site designer audiences have combined efforts to write and publish a new online guide: Design and build sites for Office SharePoint Server 2007. This guide is aimed at developers, solution designers, architects, and business unit IT pros who plan to develop one or more custom enterprise sites by using Microsoft Office SharePoint Server 2007 - such as company-wide portal sites or Internet presence sites.

Roadmaps to customization content

Office SharePoint Server 2007 includes highly customizable features and capabilities across multiple product areas, such as business intelligence, forms, workflows, and document management. The levels of expertise required to customize these various features ranges from software developer to site designer to information worker. Content supporting these customization tasks is spread across multiple Microsoft Web sites, including the Microsoft Developer Network (MSDN), TechNet, and Office Online, depending on the targeted audience for the content. Rather than duplicate all that content in Design and build sites for Office SharePoint Server 2007, the guide includes Feature roadmap pages for most customizable product areas. Each roadmap page for an area provides links to customization resources for that area, across all of the above-listed Web sites. In this guide, we include feature roadmap pages for:

Guidance for configuring development, integration, pilot, and production environments

Coordinating the development and deployment of an enterprise-level custom site based on Office SharePoint Server 2007 is quite a complex activity. Custom sites often combine coded elements, such as workflows, document converters, and Web Parts, along with content, such as master pages, layout pages, graphics files, and Web pages. We've rolled up best practices for developing these sites including instructions for setting up multiple environments for developing, integrating, piloting, and deploying the coded elements and content from one environment to another.

Our Design and build sites for Office SharePoint Server 2007 content describes how to set up the multiple environments used in the development process and describes the range of your choices for deploying the content and code from one environment to another.

Feedback wanted

We're very excited about publishing Design and build sites for Office SharePoint Server 2007, but particularly we're interested in your feedback on this new content. Do you find it useful? Is it the right level of detail? Is there additional content you'd like to see added? Do you agree or disagree with particular recommendations? We want to make this guide more and more useful in response to your feedback.

There are three ways you can provide feedback on Design and build sites for Office SharePoint Server 2007. First, in each topic you will find a "Was this information helpful?" control with a text box for supplying feedback. Second, you can send us mail at o12ITdx at Microsoft.com. Third, you can use the "Leave a Comment" interface in this blog to provide comments, either on this blog entry or on the Design and build sites for Office SharePoint Server 2007 content.

We're looking forward to hearing from you and to evolving this content in partnership with you!

Thanks,

Rob Silver

Office SharePoint Server IT Pro content team

Building a news workbench on MOSS 2007 -- Part 3

2008-03-11T03:21:00Z

[Part 1] [Part 2]

Welcome to part 3 in my series about the creation of a news management and delivery service on Microsoft Office SharePoint Server 2007. I left off last time talking about how we provide editors with a custom form to tag imported news stories as candidates for select newsletters. Let me continue by explaining how editors can use native SharePoint list features to edit selected items.

Step 3: Content Selection/Editing

As a part of this tagging action the list item is copied to another list where additional editing can be performed to prepare it for distribution and display. This secondary list - called PublishedNews - is comprised of another custom content type - appropriately named PublishedNewsItem - that essentially provides a bunch of category, date, and sort columns that we can use for querying and content display:

For each newsletter we create a Datasheet view that displays only those columns specific to that newsletter. When an editor is done querying and selecting candidates for her newsletter she can select a link on the workbench landing page to load the desired list view where she can assign values to these additional fields, such as a category header, an alternate "short" description, and a specific display order for the items.

The list of newsletters (listed under the Alerts banner) and portal pages (listed under the Content Query Targets banner) is an editable list of links displayed on the page using a Summary Links web part. This new feature is available as both a web part and field control - and provides an easy way to display a consistent (and editable!) list of links to internal and external pages. All of the links listed here load a corresponding list or page preview view for that alert or portal page.

Here is the default view loaded for the Daily Newswire newsletter listed above:

If an editor is working on more than one newsletter it easy to switch views via the view picker and perform all final editing tasks in one pass. Note that this approach also allows items to be manually added at this stage, which is convenient when a breaking news item that may not have been imported or indexed yet is required.

Step 4: Content Preview

Once an editor is done with this additional record editing she can preview her newsletter using a custom action provided in the list toolbar. This action is activated as part of a WSS Feature that we developed and deployed, and the available action corresponds to the current list view (so for the following screenshot we are looking at the "Test Alert" view so this is the alert preview that will be available for this action):

This news alert action grabs the filtered list of items displayed in the view and pops up a new page containing a custom viewer-mailer web part. This web part inserts the news items into a pre-defined template, grouping them by the designated categories, and sorting them in ascending order based on their sort field values. This web part also provides the ability to configure mail settings so this content can be pushed out to a distribution list once it is reviewed by selecting the "Send Mail" button:

For content being tagged for distribution to a portal page the process is slightly different, using Content Query Web Parts to provide the preview and published displays. I will describe this distribution channel in more detail next time.

Next Time

In my next post I'll continue describing the news delivery process, especially since we've made some changes since our initial launch to make it a little less custom-code dependent and more flexible.

Building a news workbench on MOSS 2007 -- Part 2

2008-03-03T22:22:00Z

[Part 1]

Welcome back! Last time I introduced the overall solution we developed to enable a news management and delivery service on MSW. In the next few posts I will dig into the details, providing more information on the design configuration and custom components we built.

Step 1: Content Consumption

The first step is to consume the news and insert this content into a SharePoint list. Microsoft has licensing arrangements with select information services to create topical RSS feeds of news from multiple sources. We then have a custom application that runs as a local Windows service on our web front ends, scheduled to run every 15 minutes and update a list with new items from each feed. This application uses configuration files to specify the data source and how we want the data inserted into the list.

The configuration file contains the following information:

The address of the feed
Producer and consumer assemblies
Where the data should be inserted
Arguments to add to the request
Mappings of how to insert the data into a list

Here is a sample configuration file we created for our application to read a licensed RSS feed from Moreover and import select metadata values into designated list fields:

<?xml version="1.0"?>
<FeedConfiguration>
  <Configuration>
    <ConnectionString>
       http://ps.moreover.com/cgi-local/page
    </ConnectionString>
    <ProducerAssembly>ImportToList.MSLibrary</ProducerAssembly>
    <ProducerClassName>
      ImportToList.MSLibrary.MoreoverProducer
    </ProducerClassName>
    <ConsumerAssembly>ImportToList.MSLibrary</ConsumerAssembly>
    <ConsumerClassName>
      ImportToList.MSLibrary.MswNewsConsumer
    </ConsumerClassName>
    <Server>http://localhost/Repository</Server>
    <List>NewsRepository</List>
    <Folder></Folder>
    <LastRecordProcessed>_908019085</LastRecordProcessed>
    <ItemPath>article</ItemPath>
    <FolderCount>500</FolderCount>
    <ArgumentList>
      <Parameters>
        <item name="feed">900174669</item>
        <item name="client_id">msft_cib_by49</item>
        <item name="o">xml001</item>
        <item name="last_id"></item>
        <item name="n">100</item>
      </Parameters>
    </ArgumentList>
    <Map>
      <Map>
        <Map>
          <Fields>
            <field name="Bucket" value="Daily News" />
            <field name="Vendor" value="Moreover" />
            <field name="Title" xpath="headline_text" />
            <field name="LongDescription" xpath="extract" />
            <field name="ShortDesrciption" xpath="extract" />
            <field name="VendorAssignedID" xpath="@id" 
              itemKey="true" />
            <field name="ExternalUrl" xpath="url" />
          </Fields>
        </Map>
      </Map>
    </Map>
    <NamespaceList>
      <Namespaces/>
    </NamespaceList>
  </Configuration>
</FeedConfiguration>

The key distinction for these configuration files is the Bucket field value which can be used as a property filter for the search interface (more on this in a moment).

The list that receives these news records from the feed manager is based on a custom content type that inherits from the out-of-box type Item. Essentially we are just adding the custom fields declared in the configuration file to specify where the feed data values get written to. For illustration, the schema is provided below.

And here is a sample imported record:

Notice that we aren't capturing much data; we primarily capture metadata that includes the publish date, a brief description, the news source, and a link to the full story.

This is a standard list configured to support multiple content types and locked down to permit access to only specific SharePoint groups. This list is also configured with an out-of-box expiration policy set to delete items 15 days after the Import Date value.

Step 2: Content Discovery

Even with an expiration policy in place, the list tends to hover around 30 thousand items. To assist editors with finding items in this list to tag as news candidates, we initially configured an out-of-box advanced search interface with a scope set to only index items in this list of the custom content type. Currently this crawl is scheduled to run three times per day to ensure that when editors need to use the workbench, they can query for recent news items.

We have since updated the search experience with a custom metadata interface that can more easily expose to users the available property values for managed properties. This improved interface provides greater query flexibility and a UI that can be easily updated through a web part configuration file. Our custom solution still takes advantage of the SharePoint OM and leverages full text indexes for performance.

Here is the current interface. Notice that it exposes the values of the Bucket field as a multi-choice display, allowing editors to easily scope their searches to select feed items:

Returned results can then be tagged as candidates for subsequent editing and distribution. To do this we edited the XSLT file of the search results web part to provide a link for each search result to a custom list form:

Selecting the Tag item for publishing link pops up a custom form that allows an editor to target a story candidate for one or more pre-defined newsletters. This list of available newsletters is generated from a configuration list created at the time of solution deployment and stored in the root of the site collection. This list can be modified to support the creation or removal of targets.

Once the selections are made, this form kicks off a custom action to save the selections back to the list and copy that selected item from this source list (called NewsRepository) to another list (called PublishedNews). Although we could have managed the selected news in the same list, we elected to use two lists for the following reasons:

List items are automatically crawled by the indexer and become part of the site search. We didn't want to expose all news to end users through search because a lot of what we pull in is irrelevant; as much as we try to filter, we still get news about the Spice Girls' latest concert plans, etc. The way we get around this is to lock down permission on the Repository so that even though the list gets indexed, search results don't contain any items from the NewsRepository for average users.
The PublishedNews list is smaller, so we get better performance when we query against it. And as you see later, we point a lot of Content Query Web Parts at this news list!

Next Time

In the next segment of this series I'll talk about how the editors use the PublishedNews list to prepare items for distribution and display.

Dynamically filtering the Content Query Web Part

2008-02-23T02:05:00Z

As we've often written in this blog, the Content Query Web Part is a great tool for aggregating portions of your site's content based on certain rules (filters, sorts, groupings). However, out of the box the web part is pretty static in what piece of content it shows. For example, if I configure the web part to show the latest 5 documents of type "Press Release", the part will always show the latest 5 press releases. What if I want to do something more dynamic, based on the context of the current page?

Andrew Connell has published a post on how to add dynamic filtering to the Content Query Web Part. Andrew describes a case of making the web part filter dynamically based on query string parameters, and provides a sample, too. Thanks Andrew!

--George Perantatos, ECM Program Manager

Building a news workbench on MOSS 2007 -- Part 1

2008-02-19T03:03:00Z

[Ed. note: This is the first of a five-post series about a solution that our Microsoft Web enterprise portal team built that deals with collecting, organizing, and publishing news content. We thought it would be interesting for people to read about the solution and understand how it was built. As always, use comments to ask questions! Thanks --George Perantatos]

Hi there. My name is Sean Squires and I'm a Program Manager for the Microsoft IT Information Services group. We are responsible for driving technical design and solution creation for many internal portal properties running Microsoft Office SharePoint Server (MOSS). We also work closely with the product group evaluating new features and showcasing innovative ways to extend the product. George Perantatos, a recent contributor on this blog, invited me to share with you over a series of posts how we leveraged the many new publishing features of the latest release to create a news workbench solution for our primary employee communication portal, Microsoft Web (MSW). If you've caught any of our conference talks over the past year, we've briefly described some of the various components of the solution, but never provided a full overview. Enjoy!

Business Problem

The news workbench solution was originally conceived during the redesign of the MSW portal from SharePoint Portal Server 2003 to MOSS 2007 - to address the problem of effectively managing the discovery, selection, and distribution of news content published to the site or emailed to subscribers. The previous model was a very manual process; it was difficult to manage and was prone to user error. In rethinking the news publishing process it was important to figure out how to streamline it, automate steps where possible and, of course, leverage as many of the new content management features in MOSS as we could.

Solution Approach

Our approach was to build a workbench platform that would allow editors to easily perform in a single place all of the various tasks associated with their daily publishing cycle: to find, tag, edit, and distribute select news items to multiple targets. While we needed to build a few custom components, most of the design takes advantage of new features, search, content types, information management policy, and data roll-up via the Content Query web part (CQWP).

The workbench itself is a hidden publishing sub-site in the MSW site collection composed of two lists and a few search and preview pages in the Pages library. News items are first imported from external vendor feeds on a scheduled basis into a source list, and then crawled to provide a searchable index for editors. Permissions to this list are locked down to editors only to prevent portal visitors from getting non-related news through searches.

Editors have a custom advanced search page allowing them to tailor searches against this seed list. Items returned from a query can be selected for one or more distribution channels; these candidates are then copied to another list which allows for additional editing and specifying attributes such as category and sort order (we'll talk about this in more detail in the next post).

Once items are edited they can be previewed and published to a SharePoint page using the Content Query web part. We use the same page model to surface stories on archive pages for a prescribed amount of time after their initial run. They can also be packaged up and sent out via email to a specific subscriber base using custom mailer web parts. News items published to the portal or to newsletters are eventually flushed from the list using the out-of-box policy management feature.

Here is an overview diagram of the design and various components in the process:

Next Time

In my next post I'll talk more about the custom feed management process and how we provide updated news content to the editors for use on the site.

Announcing the DoD 5015.2 Resource Kit for SharePoint Server 2007

2008-02-09T20:03:00Z

[Cross-posted from the SharePoint Team Blog.]

Back in May of last year, we announced that MOSS 2007 had passed the U.S. government's DoD 5015.2 certification. Now, all of the work that was done to achieve that important milestone has been packaged and released as a resource kit.

The DoD 5015.2 Resource Kit is intended only for customers, who are required to run their records management system in a DoD 5015.2 Chapter 2 certified state. In case you're wondering, we currently have no plans to provide support for DoD 5015.2 Chapter 4 (classified records).

However, the Resource Kit is not intended for customers, who would like to enhance the records management functionality of MOSS 2007 with particular 5015.2 oriented features but are not required to run their system in a certified configuration. Alternatively, sample code and documentation will be available shortly via the MSDN Dev Center for MOSS 2007 for the most frequently requested features such as:

Generating a Unique ID
Display search results in Grid View
Referencing and Linking - Using a secondary table to maintain the relationship
Referencing and Linking - Using the asset picker
Referencing and Linking - Using a custom field to display the relationship
Create Document Library from a list item
Put multiple items on Hold using SPQuery
Custom expiration formula based on metadata (2 parts)
Custom expiration formula based on metadata (cont.)
Creating a custom router & extracting date received (2 parts)
Creating a custom router & extracting date received (cont)
Prevent record modification but allow metadata modification in event handler
Prevent record modification but allow metadata modification by overriding upload page
Programmatically defaulting/inheriting a field value
Using ProcessBatchData to batch update list items
Using Metadata tags to route documents into document libraries
Create a record category programmatically (2 parts)
Create a record category programmatically (cont)
Routing content to a record category based on a metadata value

Officially, the DoD 5015.2 Resource Kit for SharePoint Server 2007 is now available to customers through our partner and Microsoft Consulting Service (MCS) channels. The reason for requiring partner/MCS involvement is that DoD implementations are not as simple as a "double-click installation." They require deep understanding of records management practices as well as business process and policy requirements. In order to successfully implement a DoD 5015.2 certified solution based on MOSS 2007, customers should work with their respective Microsoft account managers to engage a partner that has been trained on the DoD 5015.2 Resource Kit. Partners may download the Resource Kit's source code for free via MS Connect's DoD 5015.2 Resource Kit Source Code download site.

Also on the download site is a DoD 5015.2 Resource Kit Installer that partners as well as customers can download only for evaluation purposes and not for production use. This additional download provides a way for evaluators to learn about the DoD 5015.2 oriented records management capabilities provided by the Resource Kit while deciding which features, if not all, will be suitable for addressing their organization's requirements. [Caution: This is an unsigned debug build of the Installer for early preview purposes. The official Microsoft signed version of the Installer will be available on Microsoft.com's Download Center within a couple of weeks.]

For the latest answers to frequently asked questions about the DoD 5015.2 Resource Kit for SharePoint Server 2007, go to http://www.microsoft.com/sharepoint/capabilities/ecm/dod5015.mspx.