Tag Archives: sharepoint

Tips for SharePoint Site Owners

So you’ve decided to take on the task of becoming a SharePoint site owner! Before you dig in and set up your SharePoint site, there are some critical responsibilities you should consider.

First, a SharePoint site is not a fire-and-forget web site. It requires your attention and ongoing tweaking to be the faithful companion you need it to be for your business. Without proper attention, a SharePoint site will become lonely as no one will want to visit or use it. It may feel neglected and become unruly. It may even act out, by performing data dumps, bringing down servers, or becoming infected.

To help you with your new role as the proud owner of a SharePoint site, LearnNowOnline has enlisted the help of SharePoint site whisperer Philip Wheat. Philip has collaborated with us in the past on our courses for SharePoint 2013 Application Model and SharePoint 2013 Administration. Now Philip has joined forces with us to create a couple of great courses designed for those of you who wish to take on the task of becoming a SharePoint site owner.

SharePoint 2013 Site Owner: Templates
This course will help you understand what being a SharePoint Site Owner is all about, and what tasks and capabilities you’ll need to master in order to make your SharePoint site a success. You will learn how to set a baseline for those SharePoint capabilities you are likely to be concerned about, and you’ll learn the base capabilities of the various SharePoint templates as they come right out the box. Watch the course trailer:

s3o1-300x217


SharePoint 2013 Site Owner: Managing Sites

In this course you’ll learn the basics and functionality of managing your SharePoint site and site collection. You will understand the various tasks and items you need to know in order to operate your site on a day-to-day basis and ensure the best user adoption. You will also learn about additional features that can really make your SharePoint site shine. You will learn about Office integration aspects and how you can use workflows to make your SharePoint site operate as an application platform without a complex development effort. By the end of the course, you will understand the items you’ll need to operate your site, important takeaways to remember when setting up your site, and tips for gaining adoption and usage of your site. Watch the course trailer:

s3o2-300x217

These SharePoint Site Owner courses are now available, visit www.LearnNowOnline.com for more information including course outlines. With the help of LearnNowOnline and Philip Wheat, our SharePoint site whisperer, your SharePoint 2013 site will be a faithful companion to your business and loved by all. Your site users will be amazed at how well behaved your site is and will want to visit it often.

About the Author


brianblogpic-150x150

Brian Ewoldt is the Project Manager for LearnNowOnline. Brian joined the team in 2008 after 13 years of working for the computer gaming industry as a producer/project manager. Brian is responsible for all production of courses published by LearnNowOnline. In his spare time, Brian enjoys being with his family, watching many forms of racing, racing online, and racing Go-Karts.

 

8 Key Players in Your SharePoint Rollout, Part 2

SharePointRolesCloud

In my 5/12/2014 post I took a look at one of the main reasons many SharePoint installations fail—lack of user buy-in. One of the best ways to get buy-in is through SharePoint education. Then in my 5/29/2014 post, I began to look at some of the primary roles within a company that are involved in planning and implementing SharePoint. I covered how targeted and structured training within these roles can create an environment where communication can flow freely, resulting in SharePoint deployments with a high rate of success.

In this post, let’s take a look at the remaining roles within a typical SharePoint deployment, and why they also need a solid understanding of SharePoint in order to obtain buy-in, and thereby create the necessary steps to insure a high level of success.

Developers

Developers are given the task of implementing the business logic that controls the document flow within SharePoint. Typically this should be the most obvious place to throw training dollars, but surprisingly many companies don’t believe it necessary. They feel SharePoint development is no different than any other Web development so why bother. Unbeknown to them, they have now greatly increased their chances of stepping on one of the biggest landmines in SharePoint deployment—code from an uneducated developer. SharePoint provides a very powerful framework that gives developers a huge amount of leeway on how they can extend it. Not taking the time to understand the pros and cons of all options can jeopardize the security, stability and maintainability of a SharePoint installation.

SharePoint can also suffer from poor coding practices. There are many development tools and concepts that can be leveraged to extend SharePoint from C# to MVC, from JavaScript to Entity Framework. Each area can introduce a weak spot if developers are not up to speed on the latest coding practicing or versions. Companies that want to maximize their chance of a successful deployment should make sure that their development teams have the right knowledge so they can make the best decisions and build components and workflows that are rock solid.

Designers

Depending on the size of the company, the design of the SharePoint site might be controlled by a team other than developers. Designers are responsible for the look and feel of the site and likely do not have a strong programming background. They may control areas like images, color, fonts, logos, layout, and branding that are implemented throughout the site.

Since part of the success of any SharePoint deployment is getting your employees to use it, attention to design and the user experience cannot be overlooked. Your design team needs to become familiar with SharePoint and understand how people will use it, so they can then design a solution that is easy to use and increases productivity. Any solution that creates a burden on performing even the simplest of tasks will not be adopted.

Administrators

Another key role in the deployment of any SharePoint installation is the administrator role. This person is the infrastructure guru that is ultimately responsible for allocating internal resources and installing all the services necessarily to get SharePoint up and running. The administrator will, of course, be guided by the detailed plans laid out by the infrastructure architect. Clearly this is a role that needs to have a firm understanding of SharePoint. Bad decisions by the administrator could lead to security breaches, loss of documents, degraded performance and/or site outages. Each of these could break the trust of its users, leading to a slow adoption curve or even no adoption at all.

Site Owners

Once SharePoint is installed and operational, the task of configuring SharePoint falls to the site owner. In many smaller installations, the site owners and champions will be the same person. Since the champion role requires a much deeper understanding of SharePoint, and therefore much more training, many larger companies may elect to limit the number of champions to what they need, and instead have additional site owners.

To make SharePoint more manageable, companies will break up SharePoint in many ways (by department, region, floor, rolling dice, etc.) since it is impractical for one person to manage it at the global level. By dicing the site up into pieces, individual site owners can customize the look and feel, as well as security, to meet the direct needs of that group.

Site owners are like mini-administrators. They have full control over their little piece of SharePoint and are responsible for creating and managing their site or sites. This may include the type of templates and document libraries used, as well as creating users and assigning access rights. There are still needs that would require going to the company administrator…for example, if their site runs low on storage space.

Even at this level, education and training is very important because these site owners need to understand how to do the tasks necessary so their users have a positive and engaging experience. This is the last group to influence SharePoint before it goes live.

Power Users and Business Users

Now that your SharePoint is live, the education needs don’t stop. You’ll likely have hundreds or even thousands of employees who can now take advantage of the power of SharePoint. But will they use it if they don’t understand it? Often users tend to get intimidated by SharePoint. They have been doing things one way for so long that it is difficult to trust that a new way would be better. The quickest way to gain trust and increase engagement with SharePoint is through training—successful SharePoint deployments always include training for their general users. That way they can feel comfortable working in this new environment right off the bat, and can more easily trust that this new way of doing things will be a better and more productive way than before.

In Summary

Creating a successful SharePoint deployment requires a conscious buy-in to the solution that starts from the top of the organization chart all the way down. Any member of the team who doesn’t understand or doesn’t trust the solution will be a kink in the armor. Too many kinks will cause the solution to stall, falter or fail. To get everyone’s buy-in, the best prescription is education. By training the top, you can be sure that the design and necessary resources will meet the needs of the business. By training architects, developers and administrators, you can be assured that the installation is rock solid and performs well. By training at the user level, you can be confident that the solution will be adopted and the company will reap the benefits.

Finally, I want to give a shout-out to one our indispensable SharePoint gurus and instructors, Philip Wheat, who assisted me in putting some of the content together for this blog series.

About the Author

martysMartin Schaeferle is the Vice President of Technology for LearnNowOnline. Martin joined the company in 1994 and started teaching IT professionals nationwide to develop applications using Visual Studio and Microsoft SQL Server. He has been a featured speaker at various conferences including Microsoft Tech-Ed, DevConnections and the Microsoft NCD Channel Summit. Today, he is responsible for all product and software development as well as managing the company’s IT infrastructure. Martin enjoys staying on the cutting edge of technology and guiding the company to produce the best learning content with the best user experience in the industry. In his spare time, Martin enjoys golf, fishing, and being with his wife and three teenage children.

8 Key Players in Your SharePoint Rollout

In my previous blog article, Is Your SharePoint Rollout Doomed to Fail?, I took a look at one of the main reasons many SharePoint installations struggle—the lack of user buy-in. Without complete buy-in on your SharePoint solution from everyone from the CEO on down, you might as well put your IT budget on Black-13, spin the roulette wheel and hope for the best.

Assuming you’re not the gambling type, just how do you tackle the training of your company in SharePoint? Who are the key players that require their own unique educational approach? In this post, we will begin to take a look at a typical SharePoint rollout, the roles involved, and what each role should know.

CEO/Executives

Unfortunately, many companies fail to include one of the key roles in any SharePoint rollout, upper management. Don’t get me wrong, I’m not suggesting they are purposely kept in the dark. It is more about the level of engagement. Your CEO sets the tone for the company and everyone else tends to follow his or her lead. If the CEO doesn’t completely understand the value, or the ROI, of their SharePoint solution, they will more than likely take a wait-and-see attitude towards the project…especially if the solution is sold and managed by the IT department. This attitude will trickle down and soon you will find yourself with a SharePoint site that no one uses or even cares to use. Why bother? No one has any “skin in the game” as they say.

Proper education of your executive team is important so they understand how their company will benefit by implementing SharePoint. Once they are on board, they will insist that each department be on board as well, and so on. So, does the CEO need to become a SharePoint developer? Of course not. But they need to see the big picture and understand the challenges that your SharePoint project will overcome.

Ok, you have upper management’s buy-in. Who’s next?

Architects

There can be up to four architects required for a SharePoint implementation, depending on the size of your company. Smaller organizations might consolidate the architect roles into just one or two.

The two most important architects are the:

  • Business architect – This person is focused on the business needs of the company and the business problems that the SharePoint implementation is trying to solve.
  • Technical architect – This person is focused on the technology requirements. The technical architect needs to work with the business architect to make sure the organization has the network infrastructure and resources necessary to support the SharePoint implementation.

The other two architects who should be involved are the process architect and the infrastructure architect. Once the business and technical architects iron out a plan, the process and infrastructure architects start working on how to implement it using the available resources.

  • Process architect – This person develops the business logic to support the plan and may even get into where the business logic resides, such as workflows, custom applications, templates, etc.
  • Infrastructure architect – This person works on the network and server requirements. Do we need more servers? Can we provide adequate security? How can we insure high availability?

Do these architects need to understand SharePoint? Absolutely! But here’s the key. Most companies don’t go far enough in getting the people in these roles sufficiently up to speed on all that SharePoint has to offer. Remember, SharePoint is a framework. This means it comes with an infinite amount of uses and many ways to implement. A common mistake is not thoroughly investigating the options available, and therefore going down a road that is misinterpreted as the only road available. It is common for a SharePoint implementation to be crippled right out of the chute due to poor architecture.

The cure…training, of course. Architects that have gone through a detailed, structured training program are more likely to work better together and come up with solutions that lead to a successful implementation of SharePoint. And in the end, this will draw out the architects’ buy-in which you needed all along.

Champions

Different companies label this role differently, but for the sake of this blog I’m going to refer to this particular role as champion. Most companies do not have, nor do they really need, an abundance of architects. But what you’ll find is that once the solution is deployed, everyone wants access to the architects. SharePoint is not a trivial solution and once things roll out, there are few people that really understand the solution at a high level. And unless you have a cloning device tucked away in your back pocket, you’re going to need more people to support the solution.

Champions are the ones that understand SharePoint at a high level and are usually trusted with administrator rights on the servers. They are then available to assist departments with site creation, security, major functional changes in business logic, and the like. It is also common for companies to assign the role of SharePoint Site Owner to these people as well, depending on the overall size of the company. These roles have a lot in common.

Clearly this role also requires getting up to speed in SharePoint. Just like with the architects, the people in this role will need a detailed understanding of SharePoint so they can effectively build and configure sites that are aligned with the goals of the company. With champions on board, your chances of a successful SharePoint rollout are greatly increased.

Next Steps

These roles provide you with a solid foundation to begin building your SharePoint implementation. Education plays a critical role here because it allows efficient communication to occur between all your major departments. When everyone understands the power and wide range of features that SharePoint brings to the table, great ideas and great solutions have a chance to come forward.

In my next blog, I will dig into five more roles that are critical to a successful SharePoint rollout: Administrator, Developer, Designer, Business/Power User, and SharePoint Site Owner. Stay tuned…

About the Author

martysMartin Schaeferle is the Vice President of Technology for LearnNowOnline. Martin joined the company in 1994 and started teaching IT professionals nationwide to develop applications using Visual Studio and Microsoft SQL Server. He has been a featured speaker at various conferences including Microsoft Tech-Ed, DevConnections and the Microsoft NCD Channel Summit. Today, he is responsible for all product and software development as well as managing the company’s IT infrastructure. Martin enjoys staying on the cutting edge of technology and guiding the company to produce the best learning content with the best user experience in the industry. In his spare time, Martin enjoys golf, fishing, and being with his wife and three teenage children.

SSRS 2008: Reporting Services and SharePoint

SQL Server 2008 Reporting Services supports two different installation options:

  • Native mode. The Report Server controls all report execution, rendering, and management.
  • SharePoint integrated mode. Report Server runs as part of a SharePoint server farm. SharePoint provides front-end access to content, management, and security. The Report Server takes care of report execution and rendering.

In order to use SharePoint integrated mode, you must have installed Windows SharePoint Services 3.0 or Office SharePoint Server 2007. You also need to configure Report Server for SharePoint integrated mode.

TIP:An alternative to deploying Reporting Services in SharePoint Integrated mode is to deploy Reporting Services in Native mode, but to use the Reporting Services Web parts to find and view reports from SharePoint.

Why Use SharePoint Integrated Mode?

SharePoint Integrated mode makes the most sense when your organization has made a strong investment in SharePoint and you want to leverage that investment when creating, executing, and managing reports.

A number of Reporting Services features are only available when working in SharePoint Integrated mode. When in integrated mode, you can:

  • Manage reports, data sources, and report history using SharePoint.
  • Use the document management and collaboration features of SharePoint with reports.
  • Make use of SharePoint managed authentication and authorization for reports. This includes the use of Forms authentication.
  • Distribute reports outside of a firewall using SharePoint.
  • Deliver reports using a SharePoint delivery extension.
  • Create custom integrations between a SharePoint site and Reporting Services using the ReportingServices Web services API.

A number of Reporting Services features are not supported when the Report Server is configured for Integrated mode. These include:

  • Report Manager
  • My reports
  • Linked reports
  • The rs.exe command-line utility

NOTE While there is much in common across Native and Integrated modes, where there is a difference, this course will cover the Native mode approach.

TIP: See SQL Server 2008 Books Online and your SharePoint documentation for guidance on SharePoint-specific features and interfaces.

paul_LitwinPaul Litwin is a developer specializing in ASP, ASP.NET, Visual Basic, C#, SQL Server, and related technologies. He is an experienced trainer, has written articles for MSDN Magazine and PC World, and is the author of several books including ASP.NET for Developers (SAMS) and Access 2002 Enterprise Developer’s Handbook (SYBEX). Paul is a Microsoft MVP, the chair of the Microsoft ASP.NET Connections conference, and a member of the INETA Speakers Bureau.

Core Foundation Assemblies

Before you can write any managed code for SharePoint you must reference the assembly that contains the classes you need. Although there are many assemblies in a SharePoint installation, there are a few that you will use often. If you are using one of the SharePoint project templates in Visual Studio 2010, the appropriate references are usually preconfigured when you create the Visual Studio solution.

The most commonly used assemblies are in the SharePoint root within the ISAPI folder although there are many located in other places, especially in the global assembly cache. Some of the most commonly used assemblies are:

  • Microsoft.SharePoint: The core classes for SharePoint Foundation.
  • Microsoft.SharePoint.Client: The core classes for client applications using the managed client object model.
  • Microsoft.SharePoint.Linq: LINQ to SharePoint.
  • Microsoft.SharePoint.WorkflowActions: SharePoint specific workflow actions.

Core Classes

The classes that represent the elements common to all SharePoint sites are in the Microsoft.SharePoint assembly. Figure 15 shows a few of these classes. If you have taken the time to become familiar with SharePoint as a user, the purpose of most of these should be obvious to you at this point—SPSite is a site collection, SPWeb is a web, and so on.

corefoundationimg1 Some of the commonly used classes in Microsoft.SharePoint.dll.

SPContext

SPContext is the only class shown in figure above that doesn’t represent an item in a SharePoint site. You use this extremely handy class when writing code that runs when SharePoint renders a page, for example in a Web Part or user control, to gain access to the current request. You can use SPContext . Current to get access to the current:

  •  Site
  •  Web
  •  List
  • ListItem
  •  More…

It is important to note that SPContext is always governed by the security context of the user that is requesting the page. You can get the current user programmatically via the CurrentUser property of the SPWeb class. For example:

SPUser currentUser = SPContext.Current.Web.CurrentUser;

Because SPContext.Current uses the security context of the current user your code will throw a security exception if it attempts to perform any operations that the user does not have permission to perform.

Common Conventions

As you saw in Figure above, it is easy to guess the names of most of the core classes—just add an SP to the front of the name. For example, it should come as no surprise that the class you use to work with an alert is SPAlert! Other common conventions include:

  • An item’s name is usually the Title property such as SPWeb.Title and SPList.Title.
  • Most collection indexers provide the following overloads for accessing collection items:
    • Ordinal index
    • Guid
    • Title (if applicable)
  • Most changes to property changes only persist when you call the object instance’s Update() method.

doug (frame 367 of smile clip)This post is an excerpt from the online courseware for our Microsoft SharePoint 2010 for Developers course written by expert Doug Ware.

Doug Ware is a SharePoint expert and an instructor for many of our SharePoint 2007 and SharePoint 2010 courses. A Microsoft MVP several times over, Doug is the leader of the Atlanta .NET User Group, one of the largest user groups in the Southeast U.S., and is a frequent speaker at code camps and other events. In addition to teaching and writing about SharePoint, Doug stays active as a consultant and has helped numerous organizations implement and customize SharePoint.

Project Templates

The first thing you do when building a new solution in Visual Studio 2010 is to select a project template. The template you select determines the tools that are available and how Visual Studio behaves when you build the project. Visual Studio comes with project templates for a variety of Windows and Web application types. Among these are a number of templates for building SharePoint applications.

Several of the project templates concern development of specific types of features. Each of these is a starting point that allows you to add any type of feature, but that starts with an element manifest that corresponds with the project template’s name. The feature oriented project templates are:

  •  List Definition
  •  Content Type
  •  Module
  •  Event Receiver

Workflows are an important component of most SharePoint environments. There are five workflow specific project templates for SharePoint, two of these support workflow development for SharePoint 2007. The SharePoint workflow templates are:

  •  Sequential Workflow
  •  State Machine Workflow
  • Import Reusable Workflow
  •  SharePoint 2007 Sequential Workflow
  •  SharePoint 2007 State Machine Workflow

The SharePoint 2007 workflow templates are the only direct support Visual Studio offers developers writing code for SharePoint 2007. All of the other project templates support only SharePoint 2010.

The remaining SharePoint project templates are:

  • Empty SharePoint Project: An empty project with SharePoint tools.
  • Visual Web Part: A user control and a Web Part wrapper with a feature to add the Web Part to the deployment target.
  • Business Data Connectivity Model: A project with tools for building Business Connectivity Services applications.
  • Site Definition: A project pre-populated with files for a custom site definition.
  • Import SharePoint Solution Package: A project with imported contents from a WSP usually generated via the Save Site as Template functionality of a SharePoint site.

Most large solutions start with the Empty SharePoint Project template.

doug (frame 367 of smile clip)This post is an excerpt from the online courseware for our Microsoft SharePoint 2010 for Developers course written by expert Doug Ware.

Doug Ware is a SharePoint expert and an instructor for many of our SharePoint 2007 and SharePoint 2010 courses. A Microsoft MVP several times over, Doug is the leader of the Atlanta .NET User Group, one of the largest user groups in the Southeast U.S., and is a frequent speaker at code camps and other events. In addition to teaching and writing about SharePoint, Doug stays active as a consultant and has helped numerous organizations implement and customize SharePoint.

Site Collections

Thumbnail for 597When you access a SharePoint site with any type of client application, including the browser, you are first accessing a site collection that contains the site you ultimately want to access.

A site collection contains one top-level, or root, web, and zero or more subsites. The site collection acts as the root unit of authorization for all the webs it contains and it can exist at the root of a Web application or under another site collection.

A very important difference between a site collection and a web is that the site collection acts as a boundary for both security and aggregations. This distinction often trips people up and can cause some frustration. SharePoint has a number of mechanisms for querying and aggregating information, but they are generally limited to the confines of a site collection.

Most SharePoint items with which a user interacts exist within the context of a site collection, and an individual user can have permission to access many site collections. However, each site collection has different permission sets. In this respect, you can think of query visibility as similar to the data in two different databases that you want to aggregate by using a SQL query. In the case of databases, you generally have to use some sort of extension or intermediate step to create the correct result set. The same is true of data in two site collections.

Logical Site Hierarchy Example

It is tempting to think of a site collection as the top of a hierarchy of webs, as shown in Figure 1, because a site collection is assigned a URL when a user creates it, but this is not correct.

SiteCollections1Figure 1. A site is not the root of a hierarchy of webs.

Single Site Collection Example

A more accurate depiction of a site collection is as a container that has one or more webs. The root web uses the URL that the user specifies during the site collection’s creation.
Consider a simple company portal that is configured as follows:

  • Mycorp.com
    • Mycorp.com/Accounting
    • Mycorp.com/HR
    • Mycorp.com/HelpDesk

This topology is certainly functional, but what if the Accounting web needs a different security model and is the property of the accounting department including responsibility for user management? If so, it is possible to preserve the URL scheme with a little extra configuration and use multiple site collections instead of a single site collection containing every subsite.

Partitioning with Site Collections

By default, when you create a new site collection using SharePoint Central Administration, the URL will be something like http://myserver/sites/newsite.

The sites portion of the URL is called a managed path. Conversely, the page to create a new subsite allows you to specify the URL without the sites element, and if you want to create newsite as a subsite instead of a site collection, the URL will be http://myserver/newsite.

Consider the example shown in Figure 2. This URL scheme requires additional configuration to implement, but duplicates with site collections the URL scheme of the subsite for the accounting web.

SiteCollections2Figure 2. Managed paths allow control
when using multiple site collections in a 
single Web application.

You can duplicate the URL scheme used for a subsite with a site collection by defining a managed path.

doug (frame 367 of smile clip)This post is an excerpt from the online courseware for our Microsoft SharePoint 2010 for Developers course written by expert Doug Ware.

Doug Ware is a SharePoint expert and an instructor for many of our SharePoint 2007 and SharePoint 2010 courses. A Microsoft MVP several times over, Doug is the leader of the Atlanta .NET User Group, one of the largest user groups in the Southeast U.S., and is a frequent speaker at code camps and other events. In addition to teaching and writing about SharePoint, Doug stays active as a consultant and has helped numerous organizations implement and customize SharePoint.

Record Management in SharePoint 2010

Thumbnail for 597

 

SharePoint 2007 supported only the Records Center site template for records management, and did not provide support for records management for individual libraries on non-Records Center sites. The fact that SharePoint 2010 now has this in-place capability does not do away with the need for the Records Center site template. You would continue to choose the Records Center template for the following scenarios:

  • A centralized approach to records management is preferred to simplify auditing and reporting tasks.
  • The need exists to perform records management on entities other than document library members, such as email messages or SharePoint list items.
  • The need exists to organize archived material without requiring human intervention on submitted items.

Organizing Content

When using the centralized approach of the Records Center site, it is likely that multiple libraries will be needed for archiving records, particularly in a case that will include many thousands of documents. There are three particular problems that must be overcome in such a case:

  • Thousands of documents must be routed to the proper library to support a well-organized site, but the routing must be carried out without the burden of human intervention.
  • Users must be blocked from ignoring the routing mechanism and choosing their own destination libraries.
  • The archive site must be organized in such a way that folder content does not exceed recommended maximum capacities.

The Content Organizer feature, which is automatically enabled for Records Center sites, is designed to address these very challenges. The Content Organizer creates a special library named the Drop Off Library. This library is the central location for submitting documents to the Records Center site. Documents submitted to this library are routed to another library based on defined rules. When you author these rules you specify the following:

  • One or more conditions to determine if a submitted document matches the rule.
  • A destination library where matching documents are routed.
  • A priority value, to indicate which rule should be applied in a case where more than one rule matches a document.

If a document is submitted that does not match a rule then the submitter and the owner of the site are notified. In addition, the document remains in the Drop Off Library until the site owner intervenes with a new rule.

In addition to applying rules for routing, the Content Organizer feature also provides the Folder Partitioning capability. Folder Partitioning provides an automatic mechanism to ensure that folders do not contain an excessive number of items by automatically subdividing a folder once it reaches a certain threshold.

While you can create your own destination libraries in the Records Center site, there is a library already created for you named Record Library. The significance of this library is shown in Figure 1: Documents added to this library will automatically be declared as records.

RecordManagementinSharePoint2010img1

Figure 1. The Record Library automatically declares a document as a record.

In Place Records Management permits a user to manually indicate that a document is a record and subject to records management rules. In the case of the Record Library, the declaration is automatic: simply placing a document in this library implicitly declares that it is a record.

Managing the Records Center

While all of the settings for the Records Center site may be configured via the Site Settings page, the Records Center site template includes a dedicated page (see image below) for convenient access to site management tasks such as defining rules, organizing libraries, and generating reports.
RecordManagementinSharePoint2010img2

The Records Center Management page provides
convenient access to standard configuration tasks.

John.UnderwoodThis post is an excerpt from the online courseware for our Microsoft SharePoint 2010: Enterprise Content Management course written by expert John Underwood.

John Underwood is a technical evangelist for a SharePoint consulting company, with 30 years of programming experience, including 20 years on the Microsoft platform and 10 years with .NET. John also has extensive experience using, configuring, and programming SharePoint.

 

 

Document Sets

Thumbnail for 597When users work with documents, there are occasions where more than one document is related to a particular task or project. In the past a user might group these together within a folder in a SharePoint document library. However there are some drawbacks to using folders:

 

  • Users can sometimes find folders to be unwieldy and confusing, particularly when deeply nested.
  • Folders do not permit the documents to be acted upon as a group, but rather serve simply as a container.

SharePoint 2010 introduces a new feature, known as Document Sets, to address this situation. As the name implies, a Document Set is a special content type that allows the grouping of related documents.

While a Document Set is similar to a folder conceptually, it holds some distinct advantages over folders:

  • Document Sets appear as a single item in a library, and thus represent a user-friendly alternative to multiple levels of nested folders.
  • Document Sets support versioning, and may be versioned independently of the documents they contain.
  • Document Sets support metadata columns that can convey information about the set, such as the current state in a submission process.
  • Document Sets can be manipulated by workflows, permitting the entire set of documents to be treated as a single entity.

Before Document Sets can be used the Document Sets site collection feature must be activated. In order to use Document Sets in a particular library, the library must allow management of content types and must include the Document Sets content type.
The default behavior for the Document Set content type is to permit the user to add multiple documents to an instance of the type. However, the sets can be customized so that a specific number and type of document are automatically included in the set. As an example, a Document Set for a sales proposal might always include a spreadsheet for sales numbers, a presentation to pitch the proposal, and a document outlining the terms of the proposal. You can create a custom content type that inherits from Document Set and tailor it to meet the exact number and kind of documents needed.

Each Document Set has a welcome page associated with it. You can customize this page via the browser and SharePoint Designer to make it easy and convenient for users to consume.

John.UnderwoodThis post is an excerpt from the online courseware for our Microsoft SharePoint 2010: Enterprise Content Management course written by expert John Underwood.

John Underwood is a technical evangelist for a SharePoint consulting company, with 30 years of programming experience, including 20 years on the Microsoft platform and 10 years with .NET. John also has extensive experience using, configuring, and programming SharePoint.

Social Tagging in SharePoint 2010

As you read earlier, folksonomy is a community-driven mechanism for categorizing data where the keywords are driven by end users instead of designated taxonomists. SharePoint 2010 now offers support for folksonomy via Social Tagging. Social Tagging allows end users to tag pages with Keywords for future reference or to share with colleagues.

When a user tags a page, SharePoint searches for a Keyword or Term that matches the tag. If a match occurs then the existing Keyword or Term is used. If, on the other hand, a matching Keyword or Term is not found, then SharePoint creates a new Keyword and stores it in the special Keywords Term Set. By default, everyone can add new Terms to this special Term Set. As you would expect, the Keywords Term Set uses an open submission policy, which allows all users to contribute entries.

NOTE     Terms in the Keywords Term Set are called Keywords, not Terms.

Keywords do not support any type of hierarchy or relationship. Keywords can only exist under the Keywords Term Set and only in one flat structure.

When tagging a page, the user has the option of either marking the tag public or private. If the tag is marked as private others will not be able to see that the page was tagged, but the Keyword will be created in the Keyword Store and available for others to use. Also, if a page has been tagged by someone but the tag was marked as public, anyone else who tags that page will see that tag as a suggestion. Because of this, users should be properly trained on how to use tags to prevent tags of a sensitive or confidential nature from being inadvertently created.

Over time, certain Keywords may gain wide acceptance. In such cases, it may be useful to promote them by moving them from the Keywords Term Set to another, more formal Term Set. In this way, a Term can be promoted from a folksonomy model (Keyword) to a taxonomy model (Term). If Social Tagging is used in conjunction with SharePoint’s My Sites feature,
then in addition to tagging pages it is also possible to add notes about a page. Notes are stored on a user’s My Site for later retrieval and are viewable by everyone.

 

John.UnderwoodThis post is an excerpt from the online courseware for our Microsoft SharePoint 2010: Enterprise Content Management course written by expert John Underwood.

John Underwood is a technical evangelist for a SharePoint consulting company, with 30 years of programming experience, including 20 years on the Microsoft platform and 10 years with .NET. John also has extensive experience using, configuring, and programming SharePoint.