Article Digest:	SharePoint 2010 Log to History List workflow action nearly useless.  Method to get limited value out of this action
Article Type:	Bug, work around, annoyance, trouble shooting
Environment(s) used in:	SharePoint 2010 with SharePoint Designer 2010
Problem Description:	When you have an error in a workflow and you are using the Update Item action you will get the following error text: The workflow could not update the item, possibly because one or more columns for the item require a different type of information.
Design Criteria & Constraints:	NA
Technologies Used:	SharePoint Designer 2010
Third-Party tools, utilities, products used:	Perhaps ULSViewer if you dare

 

If you have worked with SharePoint 2010 Workflows created in SharePoint designer for anytime and have used them for anything but the most simple of workflows, you are aware of the value of the Log to History List workflow action.  In SharePoint 2007 you could place this workflow action before a step to log something like “Changed widget type from thingy to gizmo (step 3).”  If there were an error with the actions in step 3 you could see where there error was because logging would occur up to step 3 and then tell you that there was a horrible error and that the workflow could not continue.

Sadly, 2010 seems to just give you the most unhelpful error text that looks similar to the following:

 

	Date Occurred	Event Type	User ID	Description	Outcome
	6/27/2011 9:43 AM	Error	System Account	The workflow could not update the item, possibly because one or more columns for the item require a different type of information.	Unknown error
	6/27/2011 9:43 AM	Error	System Account	An error has occurred in Job Applicant - Edit Item.

This tells me there was an error which is very Microsoftian in that it is technically correct but utterly useless information.  To find out the step where this is occurring, you can use the Stop Workflow action under the Core Actions section.  Place this action after the first step that is questionable in your workflow.  When you do this, you will get the text from the Log to History List actions on all the steps up to the point where you placed the Stop Workflow action, if, indeed, all of the actions up to that point completed successfully.  Otherwise, you will get the error listed above.  In which case, move your Stop Workflow action up one and run your workflow again.  Once you have determined the offending step by moving the Stop Workflow action up or down in your workflow steps, you will have found the problem.

Hopefully Microsoft will fix this behavior in a future service pack.  Another way you can potentially troubleshoot the issue is by using the freeware tool ULSViewer on Microsoft’s site.  The caveat with using this utility is that you must run it on the SharePoint 2010 server and you need to know what you are looking for.

There may be other means to troubleshoot workflows but, since this is The Lazy Administrator blog, they wouldn’t be appropriate for me to post as they would require, well, more work.  If you have illumination to provide regarding troubleshooting SharePoint Designer workflows, please feel free to post a response to this post.

Introduction

After a number of years from having initially setup this blog and letting it languish, I have decided to resurrect it and use if for the original purpose I had intended for it.  Namely, by actually making posts to it.  In my role as IT Swiss Army Knife, I have learned a great deal in many areas of Microsoft, web, and miscellaneous technologies.  The purpose of this blog is to pass on some of that knowledge so that you, if you happen upon this blog in a Google or Bing search while looking up an issue or how to do something, won’t have to go through the same agony that I did in getting X to work.

Purpose

When it comes to network administration tasks, I would much rather write a script to perform repetitive tasks than to do them manually myself. There's nothing I dislike more than repetition. I would rather spend 6 hours writing a script to perform a repetitive task that would take me only 30 minutes if I were to do it manually. I guess what it comes down to is that I like writing scripts.  I also dabble in web application solutions built upon SharePoint technologies and other orchestration/automation products such as Opalis, SSIS, SCOM, etc.  In my tenure within IT, I have gathered a cadre of scripts, solutions, utilities, etc. that effectively tie together much of the corporate environment in which I am responsible for.  Surrounded by all these creations of mine I could be likened to one of those people who collects lots of land yacht for their front yard – many of which languish and rust. The mentality is that someday I'll need that rear view mirror or carburetor or flux capacitor – and, oh, what a deal!

Scripts are like that. They accumulate and sit in a directory on a server somewhere waiting to be used - they may never be used again. But with each script that I write I learn a little more and I often cannibalize code from previous scripts that I have created. Some are one-use scripts some are ones that are used on a daily basis. Overall, I have saved myself a lot of time with the scripts that I have written and the purpose of this blog is to share those scripts with others that they may benefit and save time so that they can devote more time to being lazy.  Keep in mind that there are many ways to approach the solution to a problem.  The solutions that I come up with here are the easiest based upon the knowledge that I have at the time I create the solution.  It doesn’t mean that they are always the best solutions.  Perhaps with perfect knowledge and an unlimited amount of time I could post the best solutions every time.  But remember, this is the Lazy Admin blog, so I don’t have to meet that standard.

Background

The environment that these solutions come out of is a corporate one with about 230 servers and 4500 workstations. I am in a business that does 75% of its business between November 1st and December 24th so there are some particular challenges in that environment as the number of users, servers, and workstations grow significantly during that period of time. We run Active Directory 2008 R2 in 2003 functional mode (soon to be 2008 R2 functional mode as soon as we upgrade our Exchange infrastructure) and are spread across multiple sites - many of which have AD controllers and other servers. Additionally we use Symantec Antivirus as our corporate virus protection and Quest tools for AD management.

The scripts I have written pertain to these products and filling some holes in those products or augmenting them. Some of the scripts here will address those challenges and may not be particularly useful to people but I'll include them anyway because they have a lot of components which can be used in other scripts or customized for specific environments. My preferred scripting languages and environments are:

• Batch language (*.bat, *.cmd)
• Kix 4.x for login scripts (*.kix)
• ASP for web pages on IIS (*.asp)
• HTML (*.htm, *.html)
• CSS
• VB Script (*.vbs, *.wsv)
• SQL for database queries
• XSL/XSLT
• WMI
• Javascript
• PowerShell
• HTA

Additionally I will touch on products such as:

• SSIS
• SSRS
• Opalis
• SCOM
• Active Directory
• DNS
• SharePoint (2007 & 2010)
• SCVMM
• MSCS
• Office Suite
• SharePoint Designer
• Whatever

I make no pretense of knowing anything about PERL, Python, C#, etc. so you won't likely see them here. I have borrowed heavily from examples on the internet and have most often modified that code to make it my own. I will attempt to cite code example sources where I have left code in-tact without modification.

Conventions

I am going to attempt to post entries that follow a template for the introduction part of the post so that I am consistent in the information that I present and also to help with searching and classification.  Below is the format that I plan to follow.  This will likely be organic as I will find that I have forgotten something or have perhaps have included something that is completely useless.  I will update this page to reflect the latest template that I am using but I make no guarantees that I will go back and update all my previous posts to meet the new format if I do change.

 

Article Digest:	Each article will have a brief description as to what the article is about
Article Type:	This will list the general scope of the article.  Possible values are: Bug, work around, annoyance, automation, tip, multi-part project series, design, problem resolution, script, integration, monitoring/alerting, utility, snippet, class, documentation, procedure, web
Environment(s) used in:	Every article subject will have a type and each type has a context in which it is to be used.  I will list the environments in which the article solution was meant to be used in
Problem Description:	I will provide context as to the problem that is being resolved with the solution listed in the article
Design Criteria & Constraints:	Every solution conforms to a certain set of criteria in its design and implementation.  These criteria are always there even if that are not listed out or acknowledged in the solution itself.  The design criteria can be as simple as “I used a technology that I was most familiar with.”  I will attempt to lay out what the criteria were when I created a given solution
Technologies Used:	Many solutions require the use of multiple technologies, some, only 1 or 2.  I will list the technologies that touch on a given solution.  This will help to determine if you have those skills or not of if the environment you would like to use a given solution contains the component technologies listed.  If not, a given solution may not be a very good fit or may require a good deal of modification to meet your needs
Third-Party tools, utilities, products used:	This will list tools used in the solution.  Items such as resource kit utilities, free ware, commercial applications that are not part of the Technologies Used will be listed here

Article Body

This will contain the text of the the article, code examples, screen shots, references, etc..