Read More

Hi everyone, I am Quentin Christensen and I work on document and records management functionality for SharePoint. Electronic discovery (commonly referred to as eDiscovery) is an area we are supporting with new set of capabilities in SharePoint Server 2010. In case you are not familiar with eDiscovery, it is the process of finding, preserving, analyzing and producing content in electronic formats as required by litigation or investigations. eDiscovery is an important concern for all of our customers and given that SharePoint has grown to be an integral part of collaboration, document, and records management for many organizations, we recognize the need to support the eDiscovery process for SharePoint content.

Microsoft Office SharePoint Server 2007 included a hold feature that could be used for eDiscovery, but it was scoped to the Records Center site template. With SharePoint Server 2010 the eDiscovery capabilities have been greatly expanded to provide more functionality and the power to use these features across your entire SharePoint deployment.

In this post, I want to highlight three major improvements in SharePoint that support eDiscovery. You can:

• Manage holds and conduct eDiscovery searches on any site collection
• Use SharePoint Server Search or FAST Search for SharePoint out of box to search and process content
• Automatically copy eDiscovery search results to a separate repository for further analysis

Read on to learn how SharePoint Server 2010 can support your eDiscovery initiatives and provide you with the tools you need to manage holds, identify, and collect SharePoint content.

The eDiscovery Process

The Electronic Discovery Reference Model from EDRM (edrm.net) provides an overview of the different parts of the eDiscovery process:

SharePoint Sever 2010 addresses the Information Management, Identification, Preservation and Collection stages. While this blog post will focus mostly on the identification, preservation and collection components, SharePoint provides a rich Information Management platform for Collaboration, Social Computing, Document Management and Records Management.  This means that you can take a proactive approach to eDiscovery by putting a governance framework in place and using appropriate disposition policies to expire content. Managing content and deleting it when it is no longer needed will reduce the amount of content that must be indexed and searched, and collected for eDiscovery.  The result is that eDiscovery costs can be dramatically reduced, changing the problem from finding a needle in a hay stack to finding a needle in a hay bale. Ultimately, the key to achieving legal compliance for eDiscovery obligations is built upon a foundation of robust Information Management.

When an eDiscovery event occurs, such as a receipt of complaint, discovery, or notice of potential legal claim, the identification stage begins. Content that may be subject to eDiscovery must be identified and searches are conducted to find that content. That content needs to be preserved and at some point, the content will be collected.

The eDiscovery Features

Hold and eDiscovery

Hold and eDiscovery is a site level feature that can be activated on any site.

Activating this feature creates a new category in Site Settings that provides links to Holds and Hold Reports lists. There is also a page to discover and hold content that allows you to search for content and add it to a hold. Once the Hold and eDiscovery feature is activated you can create holds and add to hold any content in the site collection. By default only Site Collection administrators have access to the Hold and eDiscovery pages. To give other users permission, add them to the permissions list for the Hold Reports and Holds lists. This will also give access to the Discover and hold content page.

You can manually locate content in SharePoint and add it to a hold, or you can search for content and add the search results to a hold. With the Hold and eDiscovery feature you can create holds in the hold list and then manually add content to the relevant hold by clicking on Compliance Details from the drop down menu for individual items.

Then click on the link to Add/Remove from hold.

And you can select the relevant hold to add to or remove from.

By manually adding an item to hold you will block editing and deletion of that item until it is released from hold. You will notice that the document now has a lock icon showing that it cannot be edited or deleted.

Each night a report for each hold is generated by a timer job. If you need a hold report faster you can manually run the Hold Processing and Reporting timer job in Central Administration.

Search and Process

You can manually add items to hold on any site collection, which is great. But that doesn’t help you find the content you don’t already know about. What if you have a large amount of items you want to find and add to a hold? For that you can use the features on the Discover and hold content page, which is a settings page in Site Settings. From this page you can specify a search query and then preview the results. The configured search service (SharePoint Search Server or FAST Search for SharePoint) will automatically be used. You can then select the option to keep items on hold in place so they cannot be edited or deleted, or if you have configured a Content Organizer Send to location in Central Administration you can have content copied to another site and placed on hold. You may want to create a separate records center site for a particular hold to store all content related to that hold. The Content Organizer is a new SharePoint Server 2010 feature based on the Microsoft Office SharePoint Server 2007 Document Router with richer functionality to automatically classify content based on Content Type or metadata properties. Look for a future blog post covering the Content Organizer.

Holding content in place is recommended if you want to leave content in the location is was created with all the rich context that SharePoint provides, while blocking deletion and editing of content. Be aware that this will prevent users from modifying items. If you prefer users to continue editing documents, then use the copy to another location approach.

When searching and processing, the search will by default be scoped to the entire Site Collection and run with elevated permissions so all content can be discovered. The search can be scoped to specific sites and you can also preview search results before adding the results to a hold. Items can be placed on multiple holds and compliance details will show all of the holds that are applied to an item.

In summary, SharePoint Server 2010 contains key features that make it an essential aspect of your eDiscovery strategy. With the new SharePoint Server 2010 capabilities you can easily apply proper retention policies for all content and make it easier to discover content if an eDiscovery event occurs. eDiscovery often prescribes tight deadlines for production. SharePoint 2010 helps you find the right content and deliver it faster.

Quentin Christensen
Program Manager – Document and Records Management
Microsoft

Read More

There is a bit of information around about upgrading from MOSS to SharePoint 2010 and from WSS to Foundation Server but not a lot about upgrading from WSS to SharePoint 2010 Enterprise.

I just did the upgrade and I can’t believe how easy it is. The only caveat was that my WSS was pretty vanilla and only had a few lists and doc libraries. I don’t guarantee this will work for everyone.

I just followed these steps.

1. Back up your content database
2. Install SharePoint 2010 but don’t set up a site collection
3. Restore your content DB
4. Use the Mount-SPContentDatabase command using powershell. The exact instructions for this can be found here. *
5. Once the upgrade is complete your site will look like the WSS but you can use the Visual Upgrade from Site Actions to give it the new SP 2010 look.

*If you have never used Powershell before see some gotchas I wrote about here.

Read More

Read More

At this point in the journey we need to tell the VM where to find the files we want to index.
Read More

A lot of exciting things happening in the world of Microsoft Project! It’s been a year since we launched and we’re seeing great customer and partner momentum with Microsoft Project 2010! I thought I would share just a few of the recent exciting news for Project 2010:

SP1 for Project desktop and Project Server will release at the end of June 2011. You can find more detailed information on the team blog. Beyond fixes, we’re shipping enhancements that include:

• Multi-Browser Support for time entry in Project Web App
• Improved synchronization of Project tasks to a SharePoint task list on-premises or in Office 365
• Time-phased support for manually scheduled tasks
• Improvements to project scheduling in Project Web App

eWeek Microsoft Project 2010 Top 10 Features. This is great to see as it highlights features across Project 2010 desktop and Project Server 2010! You can check it out at http://bit.ly/lpQVIY.

New Project 2010 Podcast on PMI. There is a great new podcast on the Project Management Institute’s Knowledge Center site. Margaret Loosemore, a Senior Product Manager on my team, gives an overview of all the great new features in Project 2010. I highly recommend checking it out here.

Microsoft Project for the Masses. A must-read whitepaper written by Innovative-e that outlines how project management can be effectively implemented without the need for complex configuration and/or processes for specific scenarios. It includes a great whitepaper and other great artifacts like videos, templates, etc. You can download from http://www.microsoft.com/downloads/en/details.aspx?FamilyID=53cd717f-939d-4f41-921a-feb3aa9353aa&displaylang=en.

Microsoft Project Conference 2012 on March 19-22, 2012. If there’s one event you have to go to, it’s next year’s Project Conference 2012! The entire team is looking forward to this event where you’ll have an opportunity to meet the team in Redmond, the greater Project customer and partner community and share best practices. Phoenix in March is also a nice touch… nice, warm weather! While registration is not open just yet (it will be soon), you can get on the mailing list at http://www.msprojectconference.com. If you’re a partner looking for sponsorship activities, shoot me a note.

Read More

Read More

Hi there, my name is Pat Miller, and I am the development lead for the Enterprise Metadata / Taxonomy features in SharePoint 2010.  I’ve been working on the ECM team and its fore-bearers for the better part of 11 years now, first with NCompass Labs which was acquired by Microsoft in 2001, then on the Content Management Server team, then with the CMS team as part of MOSS 2007.  This is the first of many blog posts on the Enterprise Metadata Management (EMM) system in the 2010 release.  This will be the overview of the system, and future posts will drill into specific areas like event receivers, field editing and search refinements.

First, some background.  At one point during the development of Content Management Server 2002, we spent some time with the folks that run the Microsoft.com set of websites.  One of the things they were very keen on was this taxonomy system that they had built.  It seemed fairly useful, and we considered implementing something like it, but didn’t have the time, and there was a general concern that no one would actually do the work of tagging data.  During the development of MOSS 2007, we were spending most of our time rewriting our feature set to run on top of SharePoint, and once again, taxonomy fell off the list of things we were willing to tackle (and still, people would consistently say that people just don’t tag).

Around this time people started tagging things in their own world.  The rise of digital cameras and mp3 players brought a huge amount of data that for the most part, had to be marked up with metadata in order to be searchable.   Some metadata was added to the files automatically (things like date, size, camera model, etc.), but specific user information wasn’t there.  You quickly learned that if you categorized the images (either through folder location or tags) you could navigate your way through 10′s of thousands of files (images, music, etc.) the way that works for you personally, rather than relying on default information like date the picture was taken.  People became more familiar with the concept of navigating their content via metadata – "Let’s listen to all my Pearl Jam albums, I feel like listening to Electronica, find me photos of Dad".  It’s only a small step from that to wanting to impose some sort of hierarchy – find me photos of my whole family, my extended family, I want to listen to all classical music, or perhaps just from the Baroque period.  Tagging all that data really unlocked a lot of potential.

Perhaps the landscape had changed…

We decided to run with it in the 2010 release.  There were a few main tenets that we tried to let guide us:

1. No one (well, almost no one) apply metadata for the shear joy.  It’s always for a purpose.
2. #1 means that the reason for the system has to be for the end user benefit.  What can you do if you have this rich metadata applied?
3. In order for #2 to come to realization, the metadata has to be present, which means that applying consistent metadata needs to be as easy and ubiquitous as possible.

To that end, we set out to enable a bunch of new user scenarios for SharePoint 2010.

We started out the release with a blank sheet of paper and some very knowledgeable people in the information management space.  We also found that most people started twitching uncontrollably when the word "ontology" was mentioned.  ‘Tagging’ was fine, ‘metadata’ was OK, at ‘taxonomy’ they started looking for an exit.  Telling people that a taxonomy was just a hierarchy calmed them down, but the whole ontology thing was too much of a stretch.  It also complicated things considerably, and we could still get a huge amount of value out of a taxonomy, so this was our starting point.

Some features were very obvious – filtering list views based on hierarchy inclusion, search refinement, etc.  Some were a small step from this – if you have a consistent vocabulary across an enterprise, you can start to do some interesting things.  You can match areas of expertise to specific content or workflows.  You can start to relate content in totally different systems based on something with more context than a simple string.  What if you could relate your analytics content to your taxonomy system and get a real-time view of what topics people are viewing instead of simply guessing based on their position in a URL namespace?  How about overlaying your security model with your metadata so that certain people had rights to view content based on the metadata applied to it?  How about we get down to business and focus our resources and ship a compelling collection of features.

To that end, we came up with the following components in the system:

The taxonomy repository itself, we call it the Term Store.  Some companies have very top down strict taxonomies, so some term stores might have a very few people allowed to edit them.  We’ll have to support having multiple term stores.

The taxonomy system needs to be able to support a complex enterprise.  A simple flat list of strings isn’t going to be sufficient.  To that end, we support the following concepts and behaviors:

• Terms - A term is the central object in the taxonomy system.  It’s the concept itself.  It’s very hard to come up with a name for a concept and have it be sufficiently descriptive and not too vague.  Term is what we came up with.
• Labels - Terms have to be known by a bunch of different names.  When someone types "check" it should be the same thing as someone that types "cheque".  "USA" and "United States" and "United States of America" are all referring to the same term.  We call these names labels.
• Default Label - It’s a whole lot easier if one label is the default.  You can find it through any of its synonyms, but we’ll display the default label in most circumstances.
• Termset - A collection of related terms in a hierarchy is a termset.  Things like "locations" and "products".
• Term Reuse - This is a key point to the system.  If you have two termsets "Capitol Cities" and "Locations", the term "London" and all of it’s synonyms, etc. should be the same in both.  We don’t allow a term to have two parents in the same termset, but it can have two parents in different termsets.
• Homographs – A homograph is a word that is spelt the same, but has a different meaning.  You should be able to have a hierarchy that has "Paris" existing in both France and Texas.  To keep things a bit more sane for the user, we don’t allow homographs to have the same parent.
• Multiple language support - A given term has a bunch of meaning associated with it.  The translations belong to the term in the same way that synonyms do.  If a term doesn’t have a translation, we use the default language.
• Groups - Groups in the taxonomy system are simply collections of termsets that share a common security assignment.  Termsets and terms aren’t ACL’d, groups are.
• Deprecated terms - if a term shouldn’t be used any more, it can be deprecated.  This doesn’t remove it from the system, you just can’t apply it to new content moving forward.
• Terms that are unavailable for tagging - this is slightly different from deprecated terms.  A deprecated term is deprecated in all occurrences in the taxonomy and isn’t shown to the user when tagging.  Unavailable terms are only unavailable in a specific termset, and are still displayed when browsing the hierarchy at tagging time.  The purpose of this is to allow things to be hierarchical without allowing people to tag with the wrong term.  For example, in the Capitol Cities termset, you might have continents in it so that people can find a particular city, but they would be marked as unavailable for tagging (with respect to Capitol Cities) because they should not be selectable at tagging time.
• Merging terms - at times, you might get multiple terms in the system that really are the same thing.  They might be in the same termset, or they might be in different termsets.  When you merge them, you get a single term with all of the properties, and this new term will be reused in all termsets that the original terms existed.
• Open Termsets - There are times when a highly managed taxonomy makes sense.  You shouldn’t be able to add random countries to the list of known countries.  However, you probably don’t want to give taxonomy editing permissions to everyone that is creating a new codeword.  Open termsets allow content editors to add new terms to a hierarchy at content authoring time.  It’s a bit of a meeting point between bottom up folksonomies and top down taxonomies.
• Keywords - The degenerate case of a folksonomy is a simply flat list of strings.  They have no extra semantic meaning.  This is the enterprise keywords termset. Terms here don’t have a hierarchy, definitions, synonyms or translations.  However it is possible to move a keyword into a managed termset and add this additional data.
• Local termsets - The taxonomy field type gives you all sorts of useful features, but you probably don’t want "places to order food from" to wind up in your enterprise taxonomy.  Local termsets are only visible within a single site collection.

OK, that’s a nice set of features in the taxonomy system.  What do we want to do with all those terms and termsets?

The next set of features involve integrating the taxonomy system with SharePoint.  The primary place this happens is in the new managed metadata field type.  Think of it as a choice field that went to the gym.  It’s much more powerful.  The metadata field type is a normal field that can be applied to any content type (list or document library).  However it has a few nice things associated with it:

• Termset binding - You can specify what termset a field should be bound to.  You can have lots of fields bound to the same termset.  When you update the termset, all of the bound fields use the changes immediately.
• Path or node display - You can choose to display the default label of the term by itself "Paris" or its path "Europe > France > Paris".
• Multi-lingual rendering -   If a given term has been translated to a given language, when your UI is set to that language, the term translations are displayed.
• Content type syndication – This isn’t a taxonomy feature per se, but it’s part of the enterprise metadata feature set.  We allow a term store to have a site collection defined as it’s "hub".  On that hub you can publish content types, and these content types will be pushed out to all consuming site collections.  This means that in addition to having a consistent vocabulary across your enterprise, you can have a consistent set of content types using all that goodness.
• Rich editing - when you are applying a term to an item, you can search across the entire termset (including synonyms) or view the tree itself.  It makes it possible to choose from thousands of choices, which would normally break lookup and choice fields.
• Editing support in the rich client applications - the document information panel in the Office client applications allows for applying terms.
• Offline editing in the rich client applications - when you edit in the rich client applications, a copy of the bound termsets is cached locally.  You can tag on the plane.

Once data is in SharePoint, other SharePoint features can deliver additional goodness:

• Better listview filtering - not only can you filter in the normal "everything with value X" but you can also do inclusive filtering, displaying everything tagged with X or a child of X.
• Better metadata navigation behavior - The metadata navigation feature allows you to navigate through libraries using hierarchies other than the folder hierarchy.  The termset is one of the allowed hierarchy types, meaning that you can browse your libraries along multiple axes.  You can now free your data from the tyranny of the URL or folder namespace.
• Routing and policy - The document routing feature can direct your content based on the metadata applied to it.  Taxonomy fields can even be used to create folder hierarchies at the routing destination.  Retention policies can be driven off of taxonomy fields as well.
• File open / save - Can’t remember exactly where your document is stored in a large library?  You can use the taxonomy field to filter the open dialog display.

Now that we have all that nice consistent metadata on our content, we can do a few more things:

• Content by query Web Part enhancements - You can configure the CBQ to filter based on taxonomy fields, including descendent inclusion.
• Automatic search refinement - The search system is aware of all taxonomy fields, and if a result set has a sufficient amount of data with the same taxonomy fields, a search refinement will appear, allowing users to filter their data.
• Power user profile and social tagging - it doesn’t make much sense to have a corporate taxonomy and then do your social tagging using just string matching.  All of the social properties are actually sourced from the taxonomy system, meaning that you won’t get people asking you where a good place to stay in Paris, France when you are an expert on Paris, Texas.

And since we know that we can’t possibly implement every feature that everyone would want, everything is accessible through our API.  In future blog posts, we’ll go over how to use this API to deliver some compelling features.

Hopefully this is a nice introduction to the work we did around taxonomies and enterprise metadata.  We had a lot of fun coming up with the design and implementation, and hope that it resonates with you.

Thanks for reading.

Pat.Miller at Microsoft.com

Read More

As most people know by now, Service Pack 1 for SharePoint 2010 was released to the public today. There’s already been a lot of hype over some of the new capabilities such as the site recycle bin and some folks have documented/demonstrated some of the new PowerShell cmdlets that are available to manage this new [...]
Read More

SharePoint Server 2010 unleashes new features such as managed metadata and metadata navigation that make metadata even more important. But a big problem for many SharePoint projects is getting metadata onto documents. It is important to consider the tradeoff of metadata vs. user tax. As the number of metadata columns that must be filled in increases it becomes less likely that users will fill in metadata because it is that much additional work to go through and see which columns actually apply. If a large amount of required columns are used then user adoption may be slow because it is so taxing to upload content. In a very open and collaborative scenario this can be detrimental. But as the value of the content and effort to create that content increases, it becomes more likely that users will take the time to fill in the appropriate fields, especially when this operation is not frequent.

For any SharePoint project you should carefully consider what metadata will be needed to perform required operations and for users to find content. Evaluate how long it will take users to fill in that metadata, and evaluate the user impact. If lots of metadata is required but end users do not adopt the system because the overhead for creating content is high it will be difficult to have a successful implementation.

Metadata defaults help with this problem because you can automatically fill in metadata for users. If a particular field will have the same value 50% or more of the time then you should specify a metadata default to help users fill in forms faster. Metadata defaults can be specified for each column at the site level, list level, and folder level. Metadata defaults inherit from each other and the child default will always override. For example if a default is set on a folder and there are defaults for the list and the site column, the default for the folder will be applied. If there are defaults for a column and a list, but no default for a folder then when an item is added to that folder it will get the list default. When users create or upload a new item the metadata default will be applied and be displayed in the edit properties form. The user can then change the property as needed. By planning for and setting metadata defaults early it will be easier to evaluate what the metadata defaults should be and how they can be used to help make it easier to get metadata applied to items.

Metadata defaults are supported on the following column types:

· Single Line of Text

· Choice

· Number

· Currency

· Date and Time

· Yes/no

· Managed Metadata

Setting metadata defaults when editing columns:

When creating or editing a column at the site or list level there is a field to specify a default value. You can specify defaults at the site level, and then override them at the list level.

Setting metadata defaults with the tree control: 

In libraries you can use a tree control to set metadata defaults for the library and per folder. To do this go to library settings and click on the link “Column default value settings”. This will give you a tree control that you can use to navigate the folders in the library. You can set defaults at the root of the library as well as for each individual folder. Folders will inherit default values unless you specify a particular default value for the child folder.

Metadata defaults are a great way to help place metadata on columns. You can even use it to apply defaults on hidden columns so users never even have the option to edit the field, but they can use the metadata to navigate and retrieve content.

Quentin Christensen

Program Manager, Document and Records Management

Read More