Category: Top Posts

User Profiles – Creating Custom Properties

The User Profiles in SharePoint Server represent a very robust and flexible way to manage information about the members of your organization.  It can be used to fill the roll of a searchable Employee Directory, used to drive business processes and workflows, and also makes it easier to find people in the organization based on their expertise and user property attributes providing social networking functionality. 

The default properties that are created at the time of installation are just a starting point.  In this article I will show you just how easy it is to create new properties that help support your organization and business processes. 

Planning The New Property

When defining new fields here is a selection of things to consider:

  • Name / Display Name
  • Type – Wide range of field types
  • Length – Cannot be modified in some situations
  • Configure a Term Store Set – Managed Meta Data
  • Policy Setting – Required, Optional, or Disabled
  • Privacy Settings – Field level privacy
  • Edit Settings – User maintained or administrator/system maintained
  • Display Settings – Show on View/Edit/Newsfeed
  • Search Settings – Support for a user Alias (i.e. Employee ID) and if it is Indexed
  • Profile Synchronization – You also have the ability to configure a synchronization with an external system (i.e. CRM, HRIS)

In many cases the options change based on the value of previous options.  A good example is based on the settings with the Type of string (Multi Value) or the Policy Setting.

Create Custom Property Walkthrough

Since I work in consulting, much of our content is very much client focused.  This is a great example of a property that would be very important to us, but not so important for the average company.  In my case, I want to allow consultants to add one or more customer names that they have worked with.  Since this valuable information could potentially be used for a number of purposes, (like tagging) throughout the entire SharePoint environment, I have decided to create a Managed Meta Data Term Set for this property so that we can reuse the content. 

Here is a quick shot of the Client List I created in the Term Store.

Define A Term Set

To create a new property, browse out to the User Profiles Service Application (or whatever your Profile Service App is named) and select the Manage User Properties link.

Manage User Properties

A full listing of the User Properties is displayed with properties organized into sections.  They can be ordered and placed into sections as needed.  To create a new property, simply click the New Property menu item.

New Property

Complete the main Property Settings.  In many cases changes to these settings cannot be made which means the previous property would have to be deleted and recreated.  In this case I created my Clients property and set it to a multi-value string separated by semicolons.  I then pointed it to the Client List Term Set previously configured.

Property Definition

The next set of fields control how the list is displayed and if it can be edited.  In this case, I want to make it an optional property and encourage consultants to maintain the value so I will enable it in each of the Display Settings.  It is not confidential information, so I will be sure to set the Privacy level to Everyone. 

Display and Policy Settings

Here is what the current profile looks like when rendered.  You can see that the Clients field is displayed and each value a link that feeds into the People Search.

Profile View

Once the values have been crawled and are available in the search index, you will start to see results in the people search process. 

People Search

Summary

By extending the User Profiles with custom properties you can leverage the robust platform to support an organization and its unique processes and content.

Site Topology Planning and Taxonomies

In the previous article SharePoint Site Topology Planning I discussed some of the technical implications of organizing the the sites within one or more applications, site collections, and sub-sites.  The article started to get pretty long so I decided to save the taxonomy part of the discussion for a separate article.

Organizing Sites

In the previous article I addressed different types of content and using that to help segment the sites across applications and site collections.  Within a given application it is possible to provide some meaningful segmentation by configuring managed paths. 

For example, you may segment collaboration sites with the following url structure:

  • http://collaborate.company.com – Collaboration Application
    • /Communities – Communities of Practice Managed Path
      • /Proposals – Proposal Community of Practice Site Collection
      • /Procurement -  Procurement Community of Practice Site Collection
    • /Projects – Projects Managed Path
      • /Alpha – Alpha Project Site Collection
      • /Omega – Omega Project Site Collection

Organizational Hierarchies

Most people understand hierarchies, and most businesses (at least in the west) have been organized in hierarchies for many years.  It is natural for people to think of their organization in this manner, but this may not be the best way to plan for the topology of your sites.

Traditional Intranets tend to go from the largest organizational unit down to the smallest.  There may be multiple divisions, with multiple business units, with multiple departments, with multiple teams, with people that actually do the work.  Sites or portals that go 5 or more levels deep can become very difficult to manage and even harder to use.  Modern businesses need to remain agile with teams always being redefined, combined and split up.  In  most situations it is a good idea to fight the hierarchy tendencies and strive for a flatter structure. 

From a SharePoint perspective a flatter structure with more site collections will make it easier to reorganize sites and structure versus a single site collection with 5+ sub-site layers deep.  As previously discussed Site Collections can be backed up and restored with a high level of fidelity (completeness) compared to a sub-site’s export and import options.  The key to usability and manageability is to find the right amount of segmentation and site collection structure.

Finding Sites and Content in a Flat World

An alternative to a rigid hierarchy is adopting flexible taxonomies with tagging.  Tagging provides a flexible and dynamic method of describing the content and sites that can evolve over time.  A great example of this is a site like StackOverflow compared with the rigid structure of the MSDN/TechNet Forums. The flat structure decreases the chance of duplication and provides new opportunities to view the data in new and unique ways. 

The SharePoint 2010 system full supports tagging without the need for custom or third party add-on components.  I fully expect that these will be a popular feature within the new version. 

Summary

Following the guidance between the two articles you should be able to properly plan your site topology.  Assumptions and business decisions do change, but if you establish the right level of granularity with applications and site collections you will be able to migrate and relocate things as needed.

Related Posts

SharePoint Site Topology Planning

This is the next in a series of articles addressing core SharePoint implementation topics.  I hope that this is valuable to both groups looking to implement SharePoint for the first time as well as groups planning planning for an upgrade or migration to SharePoint 2010.

A Series of Containers

I tend to think about SharePoint from a container perspective.  Each of the containers has a set of settings and features that can be configured and administered for all of the containers within.  It is important to understand the boundaries of each level so that you can create a site topology that meets all of your objectives.  I’ll cover a sub-set of these I typically consider while planning the site topology.  The containers I’m going to address include:

Farm – In the context of this article, all of the Applications, Site Collections, and Sites hosted by one or more connected SharePoint servers.  I say “connected” because it is possible, and fairly likely that most organizations will have more than one Farm (Dev, Staging, Production for things like Intranet, Extranet, Internet, etc).  A farm has one or more content Applications plus additional applications for things like Central Administration.

Application – An application would be the top level address which maps to an application in IIS.  For example http://sharepoint.  An application has one or more Site Collections.  The application level is also the level where you have the opportunity to identify one or more content databases for storing the content on the SQL server.

Site Collection – A site collection has one or more Sites also referred to as Webs or Sub-Sites.

Sub-Sites or Webs – This is the smallest container which resides under and can be managed by the Site Collection.

Types of Content

The first step is identify what types of content or site(s) you expect to host.

  • Internet
  • Extranet
  • Intranet
  • MySites
  • Company or Divisional Portal(s)
  • Web Content Management (Publishing)
  • Electronic Content Management (Document Management)
  • Business Intelligence
  • Project Management
  • Team Collaboration
  • Application Hosting

Not all of those types of content apply to every organization, but it should be pretty clear that the content, the update frequency and the manner in which it is used and managed can vary quite a bit from type to type. 

Considerations of Multiple Applications

Very small companies or workgroups may be able to get by with all of the types of content hosted in a single Application, but for anything larger there should be plans to segment it to multiple Applications in the farm.

Here are some considerations when using multiple Applications:

Authentication Model – What type of authorization model will be used?  Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA).  Since an Application can only support a single authorization mode, that can dictate additional applications.

Edit:    Anders Rask was kind enough to point out some changes to the authorization model in 2010 that make the previous statements incorrect.

In 2007:  Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA).  Since an Application can only support a single authorization mode, that can dictate additional applications.

In 2010: There are two high level options; Classic which supports Windows Authentication only and Claims Based which supports one or more different providers.  Additional information can be found on TechNet’s article Plan Authentication Methods.

Sessions – When a user visits an application a session is created.  It is important to understand that their session is for a specific IIS Application so if they visit the main company portal and then click to see the MySite they may be asked to authenticate again.  With Anonymous this should not be an issue.  With Windows Integrated this should not be an issue if 1) users are using Internet Explorer 2) they access the site(s) with the same account they use to access their computer and 3) their browser is properly configured to pass logged on user information. 

Application Scoped Solutions – Solutions can be scoped to specific Applications which can provide some flexibility in deploying new features.  In a large environment it is important to only show features to the areas where they apply.

Considerations for Site Collections

The site collection has some important boundaries to consider when deciding to use one versus multiple site collections.  They include:

Amount of Data – It is important to keep your site collections at a maintainable level.  There is no hard limit, but as Site Collections grow over 40GB they can get more difficult to maintain and will take longer to restore.  SQL Server tuning becomes more critical with larger databases.  It is a good idea to segment your content across multiple site collections (and across multiple content databases) in a manner that makes sense.

SharePoint Groups – SharePoint Groups can be a good way to organize users, especially when they do not map to functional areas or groups otherwise managed in Active Directory.  These groups are defined and contained within a given Site Collection which means if you want to use them in multiple site collections they have to be duplicated and maintained separately which can be problematic.

Site Collection Administrator – A site collection administrator has great power and control within the site collection container.  A Site Collection administrator can choose themes, manage all security within the site collection, manage activated solutions and potentially deploy other customizations if policy permits.  Enabling content owners should be a top priority, and the Site Collection provides a good container for that.

Quota Management – Quotas are set at the Site Collection level so if granular quota management is required for billing or charge back purposes it may have some impact on how site collections are segmented. 

Navigation – The default SharePoint navigation provider does not span site collections (and therefore applications) which can make a standardized or unified navigation scheme difficult to maintain.  This tends to work fine for team collaboration sites, but can be cumbersome when you need to link many site collections.

Content Types – I think Content Types were one of the most important changes introduced with WSS 3.0 and MOSS.  An entire overview of content types is outside the scope of this article, but keep in mind that within the current release Content Types are created and maintained within a Site Collection.  If a Content Type applies to multiple site collections then it needs to be duplicated.  SharePoint 2010 will support farm level content types which will remove the need to duplicate them.

Profiles (WSS Only) – If you are using WSS it is important to understand that the profiles are stored at the Site Collection level.  If you add custom attributes they will need to be added to all site collections they apply to.

Implications on Backup and Recovery

There are a few different methods to backup and recover SharePoint content.  Within the context of this article it is important to understand the difference between the commands that stsadm provides. 

Site Collection Backup and Restore – Considering the boundaries previously discussed, there is a lot of extra content stored in the top level site of a site collection.  Doing an stsadm backup will provide a high fidelity snapshot of the content, configuration, workflows, and other customizations.  It is important to note that if you are moving the site collection between applications or farms that you will need to install any solutions or dependencies referenced in the current location.

Sub-Site or Web Export and Import – The Export process offered for Sub-Sites is great for archiving, but it does not provide the fidelity needed to move sites around.  It will not save workflow, features, solutions or alerts.  I’ve also had inconsistent results with DataViews on sites being migrated in this manner.

If you think you will need to migrate the content or want flexibility, it would be in your best interest to consider using more Site Collections rather than deeply nested Sub-Sites.

Upgrade and Migration Considerations

The purpose and content within a site collection or site can evolve over time.  Some sites that started very narrow in purpose may change and now warrant their own Site Collection or Application.  When preparing for a migration or upgrade it is a good time to run through this exercise again to validate the assumptions and decisions that were previously made or overlooked.  While it may make the move more difficult the changes will pay dividends over the coming years offering a system better tuned to the user’s needs and more maintainable by the site owners and farm administrators.

Related Posts

jQuery Random Quote Viewer

While doing some housekeeping recently on my personal site I was tinkering around with a pre-jQuery ajax enabled web part I had written to display random quotes from a SharePoint list on the site. The code was pretty ugly so I decided to adapt the web service call to use jQuery instead in line with the similar functions displays I’ve been deploying lately.

I thought I might take the time to share it as well since jQuery is still a hot topic.

Here is what the display looks like.jQuery Random Quote Viewer

The SharePoint list is a basic list with a column for the Quote and a column for the Author.

The code is currently hosted in a Content Editor Web Part (CEWP) and is pretty simple stuff. If you are going to use this, just be sure to put in the name or GUID of the list and the URL to the site’s list web service. Here is what it looks like:



$(document).ready(function() {
var URL = ""; // URL ex. http://mycompany/sites/sub-site/_vti_bin/lists.asmx
var listName = ""; // List Name or GUID

var soapEnv = "


" + listName + "





";

$.ajax({
url: URL,
beforeSend: function(xhr) {
xhr.setRequestHeader("SOAPAction",
"http://schemas.microsoft.com/sharepoint/soap/GetListItems");
},
type: "POST",
dataType: "xml",
data: soapEnv,
complete: DisplayQuote,
error: function(xhr) { $("#errorContainer").html('Error: ' + xhr.status + ' ' + xhr.statusText); },
contentType: "text/xml; charset="utf-8""
});
});

function DisplayQuote(xData, status)
{
var Output;
var WikiString = "http://en.wikipedia.org/wiki/Special:Search?fulltext=Search&search;="
var xmlDoc = xData.responseXML;
var ListItems = xmlDoc.getElementsByTagName("z:row") || xmlDoc.getElementsByTagNameNS("*","row");
var SelectedItem = Math.floor(Math.random()* ListItems.length);
var Quote = ListItems[SelectedItem].getAttribute("ows_Quote");
var Author = ListItems[SelectedItem].getAttribute("ows_Author0");
Output = "" + Quote + " - " + "" + Author + "";
$("#quoteContainer").html(Output);
}

While this is simple code, it can be applied to so many different things.  You can use it to generate a slide show, show random images, etc. 

The source files are available here:

 

Related Links

Using jQuery to Update an Item Without A Form

I have been investigating jQuery for about six months now. There are some great examples of it out on the Internet through sources like Paul Grenier’s “jQuery for Everyone” series on End User SharePoint as well as Jan Tielen’s blog. Most of the examples I have seen relate to using it to change style and formatting of standard content. It is definitely good at that with its rich selector formatting.

In a recent project I hit an interesting snag that was ultimately solved by using jQuery. I had an interesting project requirement for a SharePoint workflow solution where the users wanted to be able to cancel a request by simply clicking a button from a list of open requests.

Initially I didn’t expect this to be much of an issue since I had done some DataForms in the past. I ended up finding two limitations to this process though; overriding default values is not easy because the fields are databound, and any changes to any rows are saved on submit of the form. This means that if you do override the field you are looking to change, every row shown in the form would change not just the individual row for the button clicked.

My next thought brought me to building a custom web part to do this. In fact this is something I have done many times in the past for somewhat similar requests. This was not a good option though since the rest of the display could need to change frequently and really should be more dynamic and configurable. In the end the cost to maintain this would be too high.

I decided jQuery was the best solution for this particular project. It gave me the ability to keep the display as a DataView which is easily configurable, and call a script on the page that can perform updates via a jQuery to SharePoint UpdateListItems web service call.

Button placed in the XSLT of a DataView

Script placed in a Content Editor Web Part

In the end, the code was very simple yet effective. As I get a handle on all of the capabilities, I see it becoming more and more central to my development toolkit.

SharePoint Quota Management

SharePoint ships with a decent set of Quota Management tools. Many of the people I talk to are not familiar with the tools because they do not believe they need quotas. I think the tools offer valuable information that can be used to help maintain a well run farm even if strict quota management is not needed. Without the tools, you increase the likelihood of excess content being stored which leads to longer backup and recovery times and additional storage needs.

If sites really do not need to be limited, I would advocate setting the quota limits very high as opposed to not enabling them or turning them off.

Storage Space Allocation Report
The tools are available to Site Collection Administrators from the Site Settings page at the root of the Site Collection.

The tools will list out all of the content in the Site Collection. You can review Document Libraries, Documents, Lists, and the Recycle Bin.

Document Libraries – I find it helpful to know which libraries have the most content. By reviewing this list you can get an idea of which Document Libraries to target when reviewing the information architecture and taxonomy issues. This may also provide the information needed to make decisions on restructuring sites and site collections so that they are smaller and nimbler helping to reduce recovery time during disaster recovery.

Documents – It can also be informative to know how big the bigger documents are. This report will actually roll in prior versions as well so if there are a large number of versions you can review and clean up as needed. In the prior version of SharePoint it was not possible to set a maximum number of versions to save so I used this to review and manage prior versions. I had one case where there were some financial spreadsheets with over 100 versions at 75mb each. That is just wasted space unless there is a real business need.

Lists – List size can be very difficult to figure out without this tool. The number of records is important to know, but if there are attachments the list size can grow very quickly. This report will detail both the number of items, as well as the storage space consumed.

Recycle Bin – It will also report out what is in the recycle bin. There is nothing too exciting here.

How to Manage Quota Templates
The quota templates are available in Central Administration under Application Management, Quota Templates.

If you do not really want to manage quotas you can set this to a large value. If you have a charge back system in place where groups pay for the storage they use, try to identify a few different standard categories and assign a warning and max level. Here are some categories that I have used before.

• Personal Sites
• Personal Sites – Executive
• Medium Document Storage
• Heavy Document Storage
• Light Collaboration
• Medium Collaboration
• Heavy Collaboration

How to Enable Quota Management
The screen to enable quota management on a site collection is available in Central Administration under Application Management, Site Collection Quotas and Locks.

Note: If a site goes over its configured quota it will be set to locked. Even if you adjust the quota size you will still need to remove the lock.

Supporting Multiple Active Directory Domains

In many environments there is more than one Active Directory forest with users that need access to the SharePoint farm. Setting up support for users on multiple domains is pretty easy and can provide new collaborative features for users throughout the extended organization.

Trust Relationship
The only prerequisite is that there has to be a trust relationship between the forests. Users from the other domain(s) will need to be able to authenticate and access resources on the host domain.

If that trust is not in place, here is a good resource: Support for Cross-forest deployments

Setting up the Import
The Profile import settings are in the Shared Service Provider’s User Profile section. Setting up the primary domain, the domain the server is on, is pretty straight forward and the default settings should be fine.

To setup an import for additional domains click on the “View import connections” link from the main User Profiles and Properties page followed by the Add Connection item in the toolbar. Fill in the domain information and click the Auto Fill Root Search Base button. If the SharePoint Administration account does not have access to read from the target domain you will need to supply an account to read the directory.

People Picker Control
If there is a one way trust, or there are duplicate accounts (display names) on different domains it may be a good idea to set some additional properties. In the article Select user from multiple forest domains it provides a path to specify which forests to search, and allows the passing of credentials if the SharePoint Administration account does not have the required privileges.

Summary
The platform does a good job of supporting cross domain collaboration, and it is a lot easier to setup than many enterprise systems. In one environment I had to support over thirty domains so the information included above really came in handy.

%d bloggers like this: