Creating a Multilingual Sites in SharePoint 2010

As we start 2011 and reflect on 2010, one of the major initiatives for many clients was creating globalized, multilingual sites.   The message was especially clear when we spoke to attendees at events like the Enterprise 2.0 conference, KMWorld and J. Boye.  In particular, I was surprised at the number of attendees  planning or that have implemented “localized” or multilingual SharePoint applications.  Unfortunately, as I learned directly, the information available from Microsoft on all multilingual scenarios is uneven.
To their credit, Microsoft has done a relatively good job of making multilingual interfaces within SharePoint available.  Microsoft has released 40 language packs for SharePoint.  These language packs allow organizations to create sites and site collections in any of the languages supported by the language packs.    If your work involves intranet or extranet scenarios (externally facing collaborative sites for trust non-employees), the language packs will serve you well.  If you want a French or Arabic collaboration site, just create a new site and stipulate the language.  Individual users are free to contribute list items in the site’s language and see localized SharePoint interfaces.

NOTE: Tony Byrne, Founder of the Real Story Group, pointed out recently that one of the advantages of using software from larger software companies like Microsoft, Oracle and IBM is that there will be far broader and better tested multilingual support.  Many smaller vendors either don’t provide multilingual support at all or provide a far smaller set of supported languages.  Both issues could be particularly problematic for SharePoint deployments as many rely on 3rd party add-ons from smaller vendors.  You should do your homework on potential solutions to ensure they support the languages you will deploy.

Where documentation for multilingual sites falls short is in the internet scenarios – specifically creating multilingual “publishing” sites (think about the typical corporate web site).  There is some limited content in blogs, technet and MSDN.  However, this content either discusses language packs and variations abstractly or, in the case of most blog content, applies to SharePoint 2007.  All of it falls short of the quick reference needed by many organizations deploying publishing SharePoint sites. 
In an effort to provide some small assistance to other folks implementing multilingual sites, here is a quick reference list of sorts that provide details on some of the basic setup.
Variations
Publishing sites (SharePoint sites created using the “Publishing” or “Publishing with Workflow” site definitions) use a concept called “Variations” to enable the presentation of site content in multiple languages.  This concept has little to do with language packs and more to do with a basic copy process.  When you setup a multilingual publishing site in SharePoint, you designate a root site, a “source variation” site and other “variation language” sites.  As you create content in the source language site, a SharePoint timer job copies content (e.g. pages) and site structures (e.g. sub sites) from the source variation site to each of the other variation sites. 
The root site is merely the default URL for your web site; when web users navigate to the root URL, they are automatically redirected to the variation site that matches their browsers language setting.  As a developer, you can even change the logic used to redirect users to a specific language site by modifying the variations landing page called VariationsRoot.ASPX.  In doing so, you can enable SharePoint to handle other redirection processes like redirecting based on a previously selected language preference stored in a cookie or redirecting based on profile data (e.g. you know the user is based in Belgium and prefers French over Dutch).
Finding the Variations Setting and Beginning the Setup
There are two settings that control variations at the site collection level.  Both settings are found in Site Settings under Site Collection Administration.  To begin the process, you click on the Variations menu option.

By clicking on Variations you begin setting up how variations will be configured for your site collection.  In the subsequent interface, the “Variation Home” is what is called “Root Site” in this post (and what Microsoft typically calls it as well).   The variations interface is shown below:

Variation Labels
Once you’ve setup the global variations feature, you need to setup each variation label.  Variation labels represent every variation site you want to include in your public web application, including the source site.  For example, if you want to have a French (France), German (Germany), English (UK) and Arabic (United Arab Emirates), you’d need a total of four variations.  Of those variations, you’d pick one to be your source variation; the rest would receive content created in the source. 
When you create the labels for the first time, you start by creating the source label.  In our example, we’ll call our UK English site the source.  There are a few fields to complete:

Field Name	Description	Example Value
Label and Description	This is essentially the portion of the URL that designates the site. If your web site URL was http://www.mywebsite.com/ the label portion would be inserted after the last slash like http://www.mywebsite.com/[variation label].  In most cases, the label is going to be the two-letter ISO code for the language, followed by the two-letter ISO code for the country.  Wikipedia has a complete list of the current ISO language codes  and ISO country codes.	en-gb
Display Name	This field is what will be used to not only describe the variation in the management interface, but it will also be the default name of the site when the variation site is created.  Typically the display name is the localized title of your web application.  If your web site was called “My Web Site” in English, you would enter that value for our UK English site.  For French, you might enter a display name like “Mon site Web”	My Web Site
Locale	Use this setting to specify the language represented by a specific variation.   There are numerous languages show in the drop down and potentially multiple versions of any given language (e.g. Spanish in Spain vs. Mexican Spanish).  You should choose the appropriate language that fits your needs.  This setting is used by SharePoint to match a user’s browser language setting to the appropriate variation.	English (United Kingdom)
Hierarchy Creation	This setting determines what portions of the source variation SharePoint will replicate to other variation sites.	Publishing Sites and All Pages
Source Variation	This sets whether the variation you’re currently defining is the source variation.  This setting is something that is set once on a specific variation and can’t be changed after you’ve created the hierarchy.  This option also sets the specific site definition used in creating all variations.  NOTE: only publishing site definitions (e.g. Publishing Site) are there by default.	Publishing Site with Workflow

Here’s a screen shot of the form in SharePoint:

Other Language Variants
After you’ve setup your source variant, you setup the other language variants you want to represent.  The setup process is similar to setting up the source variation, except that the check box indicating the variation is the “source” will be greyed out and disabled.
Once you’ve completed creating the other variants, click the Create Hierarchies button to begin the creation process.  NOTE: Creating the hierarchies is handled by the timer job.  As a result, you will either have to wait for the timer job to run or manually initiate the job to see the variations.  This is also true of other timer job-dependent activities like site structure and page propagation.   More information on timer jobs is provided below.
Timer Jobs
Technically there are multiple timer jobs that each handle a different aspect of the propagation process.  Each timer job runs on a different schedule.  Here is the list of variation timer jobs and the default interval:

Timer Job	Description	Default Execution Interval
Variations Create Hierarchies	This job creates the hierarchies defined in the variation labels section of the variations settings.  As you add new labels, this job takes care of creating the corresponding variation site	Every 24 hours
Variations Create Site	This job creates variation sites if the automatic creation setting is disabled in the Variations section of the site collection settings.	Every 5 minutes
Variations Propagate Site	This job creates variation sites if the automatic creation setting is enabled in the Variations section of the site collection settings.	Every 5 minutes
Variations Create Page	This job creates new pages in each of the variation sites once the page has been created in the source site.	Hourly
Variations Propagate Page	This job updates existing pages in the variation sites once an update has been made to a source page.	Hourly

Depending on your needs, you can modify the default interval to match your publishing schedule.  For example, if you publish pages frequently, you may want to increase the timing of your page propagation and creation to 30 minutes instead of an hour.
Keep in mind that there’s a version of these timer jobs for every SharePoint application (think URL).  This means that you’ll have 3x the number of application configured for variations to manage.  Thankfully, Microsoft provides a view of timer jobs per application.
A screen capture of the time job definitions for a sample site is shown below:

Additional Notes
Like much in SharePoint, the choices you make should be based on your specific requirements; there is usually more than one way to satisfy a need and multiple ways to develop a solution.  To that end, here are some notes about variations setup to help you make these decisions.

• Variations can be used for more than just language versions of content.  Microsoft documentation points out that the logic to redirect users to specific variations could be used just as effectively to redirect a client to a mobile device.  In this case your label could simply be “M” for a mobile version of your site.
• The timer jobs do not replicate other lists or libraries from one variation to another.  This means that you must create lists and libraries in each variation manually after the hierarchy is setup.  This is also true of content in those lists and libraries; the timer jobs focus on structure (e.g. sites and sub sites) and pages.  However, if secondary lists are important for your solution, consider creating a custom timer job.
• Variations are site collection bound.  This means that all variation sites are housed in the same site collection.  If, for some reason, you think you may need more than one site collection, you’ll have to recreate your variation setup for each site collection.  Each site collection would be managed independently.
• When possible, use features and feature stapling to modify the nature of any particular variation (if necessary).  For example, if you need a specific SharePoint list or library created in each variation, use a feature and staple it to each variation as it’s created to ensure the list exists.
• Content contribution is a bit trickier with variations, since each variation is essentially it’s own “web site.”  As such, you will need to spend more time training content contributors and more time supporting them.
• If you use the new managed metadata feature in SharePoint, you’ll need to provide translations for terms as well.  Since all variations are housed in a single site collection, you can even use managed metadata bound to a column vs. enterprise managed metadata to isolate terms that may be specific to your site.
• You are required to setup a root SharePoint site for the site collection.  However, once variations are setup, no one will likely see the root site (since the VariationsRoot.aspx page will be set to the home page of that site).  As such, you don’t have to do much with it.  However, you could use the site to store more global resources, like images and documents, for use across all variations.
• Especially during development, you should execute the timer jobs manually by going to Central Administration, go to the Monitoring section and click on Timer Job Definitions to find the right job.  When you click on a specific timer job, you’ll have the opportunity to run the job manually.  Manually running the timer jobs will allow you to see what’s actually happening within your sites without having to wait for the job to run automatically.

Please share your experiences with multilingual sites and what challenges you’ve had through comments on this post.  There is a lot more detail to setting up and managing variations, so the more feedback the better.

Continue to part 2 of this series

Year in Review

As we close out 2010, I wanted to reflect a bit on the past 12 months.

First and foremost, I want to thank all of our clients (new and existing) and our partners for a terrific year!  We have had the opportunity to work with some fantastic folks on a number of very cool projects.  We were fortunate to be involved in both SharePoint 2010 and 2007 projects, custom ASP.NET projects, work with our newest software partner EPiServer, continue our research work with the Real Story Group and spin up a fairly busy migration practice around Microsoft Business Productivity Online.  In fact, working on the variety of projects with a diverse set of partners and clients is one of the reasons consulting is such an interesting business.  For 2010, here is a sampling of the projects and firm types Consejo worked on and with:

• A zoo on a custom-written management web site
• A global media company on extensions to SharePoint Solutions ExCM
• A scientific equipment manufacturer, a container manufacturer and a SaaS software vendor evaluating and assessing their SharePoint implementations
• The Real Story Group, researching and writing about SharePoint
• A hospital system on both the development of an intranet and a clinician portal on SharePoint 2010
• With our partner Earley and Associates, we worked with a multi-national construction company on a global intranet design, taxonomy development and metadata definition
• With our partner Alternative Productions, we created a dynamic flash component for a sales training company and integrated it into their EPiServer-powered public web site
• A global horticulture company on an internal, custom-written management web site; our partner Graphic Insight developed the visual design and we worked with developers from i.c. stars
• Continued to support a major league baseball team’s SharePoint 2007-base intranet we implemented for them in 2008
• Providing SharePoint support services for a food services company
• Working with our partner Strategic SaaS to migrate clients to Microsoft’s Business Productivity Suite Online (and soon Office365!)

In addition to client work, we also had the opportunity to speak at various events.  2010 was a busy year for conferences and we spoke at many events this year, including:

• Hardlines Technology Forum in Schaumburg, IL
• Midwest SharePoint 2010 Conference in Milwaukee, WI
• SharePoint Summit 2010 in Montreal, Canada
• Enterprise 2.0 in Santa Clara, CA
• The J Boye Conference in Aarhus, Denmark
• SharePoint Symposium in Washington, DC (co-located with KMWorld)

In all, our experiences with our clients, discussions with firms interviewed in our research and interactions with attendees at conferences have provided us with a wide-ranging 2010. 

I would like to close this post by personally thanking all of our consultants, our clients and our partners (including the conference organizers of the various events) for a wonderful year.  I wish you all a prosperous 2011 and look forward to continuing our work!

Happy new year!

SharePoint Influencer50

Recently, Global360 and KnowledgeLake sponsored a study by Influencer50 to identify the 50 most influential folks in the SharePoint space.  If you follow SharePoint and the people who often blog, tweet or otherwise consult, you’ll know that trying to identify the 50 most “influential” individuals is no trivial task.   However, that’s exactly what the Influencer50 study aimed to accomplish.

When the study was released, I was slightly surprised to be see my name among the 50.  Though thrilled to be included with folks like Andrew Connell (Critical Path Training), Tony Byrne (Real Story Group), Tyson Hartman (Avanade) and Sue Hanley (Susan Hanley, LLC), the study got me thinking about what it means to be an influencer and how much weight to give to the study.

Rob Bogue was the first public critic of the SharePoint Influencer50 study that I’ve seen so far.  In his post, he makes his argument along a few dimensions:

1. It’s challenging to measure influence
2. Difficult to gauge how a potential buyer will react to any influence given the sheer number of variables involved
3. Influence changes depending on the situation and, to point #2, there may be influencers that are “hidden”
4. You can’t be an influencer if you aren’t directly involved in the space
5. [Implied] Vendors sponsored the study (credibility issue)
6. [Implied] The firm conducting the study is using a potentially unsubstantiated methodology

Some of Rob’s arguments are compelling.  I would wholeheartedly agree with items 1, 2 and 3.   As Rob points out, it’s difficult to “predict the weather,” due to the sheer number of variables involved.  The same is true of buying decisions; you just never know what factors are involved in getting someone to purchase software.  Further, the influencers for a given buying decision will change; in the SharePoint space, I’d rely on an infrastructure focused consultant for Farm configuration best practice more than I would someone like me who tends to be more focused on development.

That said, I’m not sure all criticisms he raises are valid.   I found the Amazon discussion regarding book sales a bit of a red herring; sales popularity does not imply fitness or validity.  I also disagree that someone like Jon Powell from Alfresco can’t be influential.  It doesn’t make sense that one would be influenced only by those folks who only support one position or another.  I think it’s reasonable that potential buyers listen to Mr. Powell as much as a SharePoint MVP; his criticisms are at least as telling as positive statements from SharePoint pundits.  Finally, while the study was sponsored by vendors, it shouldn’t be dismissed on that fact alone.  While Rob is critical of the Influencer50 list (and “top” lists in general), he is a part an “elite” list – the list of SharePoint MVPs; a fact he promotes on his blog.  Like the Influencer50, the SharePoint MVPs represent a group of individuals named by Microsoft and must fit a specific criteria.

Ultimately, any study or list should represent just a single data point in a collection of research.  SharePoint is a very broad product with lots of capabilities and it’s unlikely that any singular list, whitepaper or study could cover everything.  The SharePoint Influencer50 study is one way to discover potential sources of intelligence on SharePoint, but it’s not exclusive.  I’d recommend using a few sources of information and draw your own conclusions.

The Wisdom of letting Users “Figure it Out”

Back in July of this year, Computerworld, Networkworld and CIO all ran an the article “Telecom Giant Takes to Web 2.0.”  It was about Alcatel-Lucent’s use of social media tools.   The article opens with a quote from Greg Lowe, Social Media Strategist and Global Infrastructure Architect.  Lowe stated that the CEO told the organization to be more “collaborative.”  What immediately struck me was the response: go buy/implement a technology.

Based entirely on Lowe’s title, it appears that he is a member of Alcatel-Lucent’s Information Technology group.  Unsurprisingly, it appears as if the first reaction to the CEO’s statement was to find a tool to “fix” the problem; based on the content of the article, it wasn’t clear exactly what the CEO meant and whether another tool would be a solution foundation.  However, the approach described was a typical pattern:

1. Find a tool that seems to enable individuals to solve a problem
2. Make the tool available
3. Let the user community figure out how to make the organizational changes necessary to actually solve the problem

The trouble with this general approach is that it is often a recipe for disaster. 

Much to the credit of Alcatel-Lucent, they seem to be successful in at least getting folks to use the new tool.  What wasn’t immediately obvious, however, was whether the tool solved the problem the CEO identified.  To be blunt, does tool usage indicate the problem was solved or just that people were using the tool?  In using the tool, does it mean that quality collaboration, that fundamentally improved an individual’s ability to complete their job tasks, occurred regularly?

To CIO magazine’s credit, they did link to an article that presented a similar situation at Phillips, called “My Enterprise 2.0 Rollout: 4 Keys to Success.”  Fortunately, this article presented a far more thought out and methodical approach to using the “2.0” technologies.  The difference between the two approaches boiled down to the following (even identified as “keys to success”):

1. Develop a good strategy
   Phillips spent time trying to understand what they wanted to accomplish – not just “we need to collaborate better.”  Specifically, what will truly make a difference in our business?  If a business can’t improve productivity, reduce expenses or improve revenue, why implement technology solutions at all?
2. Lead by example
   At Phillips, the executives lead by example and leveraged the tools in their own work.  This approach provides a fantastic benchmark for the rest of the organization.  As the article points out, it’s not about an edict from above, but rather a way for the leaders in the firm to demonstrate usage and, in a way, also publicly learn from those lower in the organization.  Frankly, if an enterprise wants to make any initiative successful, employees need to understand that management supports their efforts and their work won’t be wasted.
3. Work with the user community
   Unlike the Alcatel-Lucent example, Phillips actively worked with the user community to ensure success.  The work involved in and the problems solved by the tool aligned directly to challenges within the organization; there were clear metrics for success. 
4. Allow a bit of “organic” evolution
   The article calls this concept “loosening the reins.”  Phillips didn’t explicitly create policies to govern the use of the tool.  While it’s generally a good idea to incorporate governance into the use of these kinds of tools, the idea of allowing a bit of usage flexibility is critical.  In many cases, there is insufficient data to truly understand what might or might not work in the enterprise.  Further, a certain trust needs to develop between the firm and employees – the firm needs to trust employees will use good judgment and employees need to trust the firm is making the tool available to improve productivity.  Ultimately, to be successful, there needs to be a good mix of established, general guidelines for appropriate use, as well as flexibility to enable “out of the box” usage scenarios.

When contemplating how to approach implementing these collaborative technologies in your organization, consider the four points above. The "build it and they will come" approach to technology doesn't work. However, it is a pattern that many in IT use to mostly their detriment. It's time to change the approach.

User Surveys for Intranets

Dorthe Raakjaer Jespersen (sorry for the English spelling) at J. Boye recently posted a blog entry “New Intranet: do we really need user surveys?”  It was a good read about how user-centric research is an excellent foundation for a new intranet. 

Early in the article, she points to somewhat typical exchanges between intranet managers and company management; the archetypical intranet manager management thinks surveys will help the intranet team better understand the needs of the users.  The equally archetypical manager thinks they need to start building immediately – surveys will take far to long to complete.  Dorthe goes on to provide an excellent set of talking points intranet managers can use to encourage management to agree to use surveys and highlights some of the potential risks in forging ahead without the user data.

However, once you’ve gotten approval, what’s next?  What questions do you ask?  What sort of feedback should you expect to get from your end users?  How many individuals should be included?  The answers to all of these questions do depend on what you need from your user community, the size of your organization and the scope of your intranet.  To help you get started, here are a set of basic questions we would recommend you include in your survey:

1. In what department do you work?
   This question provides context to the answers.  Expect every department to have different needs and desires.  The question may also give you a picture of future departmental participation and support, as well as an early indicator of departmental adoption.
2. What is your age range?
   This sounds like a question you’d want to avoid.  However, the answer will help you evaluate responses.  Many organizations we’ve worked with recently have somewhat older populations.  The age of an employee tends to affect what features of an intranet are compelling.  Your Intranet should reflect the population age average.  If you have a somewhat younger workforce, social features like status updates or blogs may be more compelling.  Older workforces will likely be drawn to a more “traditional” informational Intranet.  Keep in mind that you cannot and should not over generalize; age, in and of itself won’t tell you a lot.  However, the data will provide another useful dimension to the analysis.
3. How often do you use the Internet to support your work?
   In some organizations, the existing Intranet is little used or there’s no Intranet at all.  In its place, many employees will turn to public sources of content and information.  This specific question will help you gauge how much external vs. internal sources of information help people get their work done.  In fact, the answers to this question should be a limited list of options like: no access, my work is paper-based, I know the right person to ask, not interested, etc.   A side benefit of this question may be the discovery  of what services to offer through a newly designed intranet (assuming you follow-up this question with one that asks about their specific usage).
4. How often do you use the existing Intranet?
   It’s likely if you’re checking your server logs, you already know the answer to this question.  However, getting direct feedback is helpful is validating your objective data.   Where possible, include a list of selectable ranges of time like: once a day, once to twice a week, monthly, etc.
5. What functionality, types of information or content is important to you?
   Provide your survey participants with a list of functionality (e.g. applications), content and information that you’re either considering or have surfaced through the Intranet.  Let them choose what’s most important to them.  Use the answers to help guide your development.  More than one of our clients has chosen features or content poorly without this data (leading to community dissatisfaction with the Intranet).  Further, the answers can help validate or invalidate the inevitable “nice to have” functionality that often is introduced during development; if it wasn’t important to your user community, it shouldn’t be important enough to get included in the Intranet.  You can also follow-up this question with a free-text question allow people to suggest items that weren’t included in the list.

The preceding five questions should really be the start of about a ten (10) question or less survey.  In all cases, try to make survey questions very specific to your organization.  For example, you could ask about the location of the employee (if you have multiple physical locations), ask a matrix question that allows the participant to agree or disagree with various statements regarding your intranet (or what they’d like to see) and ask about usage outside of work (e.g. at home or through a mobile device), if those access methods are important. 

The survey should be one of the first exercises you perform when gathering requirements and/or intelligence on a new or redesigned intranet.  They generally provide very valuable insight into user behavior and needs, plus has the added benefit of allowing you to validate features, functions and “requirements” against direct user feedback. 

In closing, here are some other tips:

• Surveys should be only one of a few data sets used to evaluate your needs.  While it’s a good foundational insight source, it can also be misleading; if someone doesn’t have a good answer for a specific question, they may simply make something up.  As a result, the size of the survey population has to be significant enough to counteract errant responses.
• When designing the survey, keep the overall survey length to no more than 4 to 5 “pages”
• The survey should take between 10 to 15 minutes to complete; longer surveys may work, but you’ll get lower response rates.
• As mentioned earlier, the surveyed population should be significant, but also representative.  If you 10,000 employees, interviewing 50 people is insufficient as it represents less than 1% of your population.  Further, if you have a mix of factory employees and corporate, desk-bound employees, be sure to get people from both communities to participate.
• Ask relevant follow-up questions.  For example, if you ask about access methods (e.g. from home, mobile devices, etc), ask if they access the Intranet from home, because they have no access in the workplace (e.g. many factory workers have restrictive work rules that may prevent access to PCs during their shifts).
• Offering incentives for participation will greatly improve participant involvement.  Some clients offer gift cards for all participants, while others use the “win an iPod” approach with a participant chosen at random.  What you choose should reflect your culture and drive the sort participatory behavior you desire.
• Follow-up this survey with a similar version post launch.  A follow-up survey will give you very clear measures of improvement and help to establish basic metrics for judging on-going success.  For a discussion of other Intranet metrics, see a great article by Toby Ward on Intranet Metrics.

Oracle Internet Directory Membership Provider (LDAP) for SharePoint

A while back, I posted an article on how to create a SharePoint membership provider for Oracle’s Internet Directory (LDAP).   The post continues to be a relatively popular post and more than a few folks have asked for the source directly.

While I’ve generally tried to e-mail the membership class directly to anyone who requests it, simply posting it to the Consejo blog is probably easier on everyone.

Here’s a TXT version of the C# class.  While I’ve refactored subsequent versions of this class a few times, this version is still pretty raw, but functional (read: it’s a good start if you have nothing).  In this version, I used Kellerman’s Encryption Library to handle the MD4/MD5 hash format used by my client’s directory; interestingly they used one method for their test environment and one for their production environment.   While the Kellerman library is quite affordable (and easy to use), there is an open source alternative on CodePlex called .NET Crypto (Devv.Core.Crypto) as well as Microsoft’s Enterprise library, which include cryptography functions.

Other notes on the code:

• If you have a MOSS implementation, you don’t need this class.  Microsoft provides an generic LDAP provider with the full server product.  This was written for those who only have WSS and need something custom.
• The original requirements for this class were for creating a single sign-on environment between an Oracle Portal and SharePoint (sign on to the Oracle portal and get straight in to SharePoint without authentication).  As such, I didn’t write any code to handle password changes, resets or other management functions, since those would all be handled by Oracle’s product interfaces.
• I’ve only overloaded the bare minimum necessary for the membership provider to work with SharePoint (see above bullet).
• The lookup function for users requires exact matches.  In hindsight, I could have implemented the query a bit better to improve operation with the People Picker component in SharePoint; I didn’t, but hopefully you will and share it with the rest of us…
• This was originally written for WSS v3.0, but there’s no reason, with potentially minor changes, it couldn’t work for SharePoint Foundation (2010).  If you get it to work in a 2010 environment, I’d love to see the implementation and hear your experiences.

 

Click HERE to get a copy of the provider class.

Mastering Workflow Reports in SharePoint 2010

One of the challenges for SharePoint administrators is getting insight into what’s actually happening within the farm.  One element of management is workflow.  It’s not easy to discover what workflow processes are running, are there exceptions for a given process and how often is a process being used.

In the August edition of the SharePoint eZine, I discuss how to leverage workflow reports in the new 2010 version.  The various reporting and management interfaces make it relatively easy for administrators to better understand what’s happening.  While there are shortcomings in the available data (e.g. no whole farm reporting), what Microsoft provides does immediately provide value.