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..

There are a number of factors that drive a good logon script design. This post lists those that have driven the design of the scripts that will be the subject of my blogs for the foreseeable future. In the corporate environment where I work we have many specialized constraints and requirements. The complexity of these prevent an efficient administrative model that could be designed exclusively through GPO’s. Much logic has been placed into the scripts to account for a very heterogeneous environment. Below is a list of the criteria used in the design. These criteria take into account agility, flexibility, and service as an over-arching framework in which to develop.

1. Scripts should run with the assumption that no software is installed on the host system aside from the OS
   Reasoning: Logon scripts should be able to run right after a server or workstation has been added to the domain and rebooted. Build techniques may be from distribution media, image, or other process and the suite of software on the system, aside from what is included with the base OS, cannot be assumed.
2. Service pack levels and OS versions cannot be assumed
   Reasoning: Multiple OS’s are installed in our environment and the service pack level can never be assumed for a given OS due to the nature of how upgrades to new service packs are performed
3. User level permissions to directories on the C drive cannot be assumed and neither can permissions to the registry or any other location on the system
   Reasoning: New versions of OS’s often change the default permissions of various registry locations and for the file system. Local administrators may also change permissions
4. Batch scripts should be designed to run on lowest common denominator systems and should avoid commands and features that are not supported on them. Additionally, if a command is removed in later OS’s or only supported on servers and not workstations, or vice versa, it should be avoided. If the command or feature is improved on in the future then only the options that give like results across all OS’s should be used
   Reasoning: This prevents having to maintain multiple, version specific batch files which, though possible, are more difficult to account for version specific scripting
5. Scripts need to take into consideration location of logon and speed of connection
   Reasoning: In a distributed environment with multiple geographic locations the resources that are available at all locations are not uniform. Some aspects of logon scripting can be network intensive and if a link to the nearest authenticating controller or network resource being referenced is across a low bandwidth link the logon script can take a long time to complete
6. Single code base for scripts should provide functionality for different domains can be replicated from the source domain to any number of other Active Directory domains
   Reasoning: Though domains are separate, having a single code base and accounting for domain differences in the scripts where needed allows a much simpler code management scheme and standardization across domains
7. Windows 2000, Windows 2003, and Windows 2008 functional level domains should be supported
   Reasoning: If there are domain specific functions they need to be accounted for. In practice it has thus far been shown that there are not any AD domain level nuances that need to be accounted for in the scripting we have thus employed but if there are in the future, the ability needs to be available to account for them
8. Detailed debugging logs should be provided
   Reasoning: These are invaluable in troubleshooting logon scripts – especially where actions are taking place that are not visible to the user
9. Capture of logon/logoff information should be captured for every logon
   Reasoning: This information is invaluable for determining the machines that a user logs onto and when they logon as well as any other information desired to be captured at logon. This information, when placed into a relational database, provides excellent reporting and auditing information which helps with investigations and compliance issues
10. GPO’s will control running of logon/logoff scripts for all users
    Reasoning: This is functionality that has been provided by GPO’s since Windows 2000. By using this means, instead of setting each user’s profile, you can control the parameters passed to the logon scripts based upon site, domain, OU, and/or group filtering criteria. This also prevents you from having to set each individual users logon script information in the AD profile (ease of administration)
11. Capability to provide for multiple locked down desktop environments and alternate user shells needs to be provided
    Reasoning: In our environment we have locked down kiosks, cash registers, order entry/customer service systems, and the ability to logon with an ID that directs to a web site to allow users to unlock their user accounts and reset their passwords. All of these require running a user shell other than explorer.exe and require logic to load the appropriate shell
12. Uncompiled code should be used for all scripting components to facilitate easy debugging, troubleshooting, and modification. This does not include external tools and utilities that are called
    Reasoning: Scripting languages available on the Windows platform are powerful enough to support nearly any logon task that would need to be supported. Using a script technology vs. compiled code allows for easier and quicker editing and troubleshooting of code and does not require a third party tool for editing or compiling
13. External tools and utilities that are used in scripts should not require software to be installed but should be able to run stand-alone by simply calling the executable
    Reasoning: This avoids a dependency on software that may not be available and the requirement for elevated privileges of the user logging in (or elevating privileges) for the purposes of installing required software. This does not include command line utilities provided with Windows Resource Kits or other tools that run as a stand alone executable
14. Any third party executables called should be of the free license variety
    Reasoning: There a plenty of free tools available to perform nearly any logon script task needed. Where there is not a free tool available the functionality can almost always be provided for through a batch script, kix script, vbscript, or hta
15. The version of an executable called in the logon scripts needs to be capable of running in all the OS version environments supported. Sometimes this will require using an older version of a utility with less functionality
    Reasoning: This prevents having to provide and maintain multiple versions of an executable and provide script logic to determine which version to run with what parameters at logon script run time
16. Scripts should be stream lined to run as rapidly as possible. Where there are any areas where the script actions are taking place that may take more than a second or two to complete, status should display to the user
    Reasoning: Users tend to get fidgety when they are not made aware that something is actually happening even though they may not see what it is that is happening. When this happens they tend to call the help desk or end up putting their workstation in a state that requires desktop support. Additionally, if logon takes too long they will complain
17. Logon status displayed should look professional
    Reasoning: Self explanatory. If the logon process looks professional it reflects accordingly on the logon script administrator’s skills and makes the company look better if the logon process ever has any customer or vendor facing exposure
18. Ability to display date specific messages such as “Merry Christmas, Happy Mother’s Day” etc
    Reasoning: Tradition. Not entirely necessary
19. Display of acceptable use policy
    Reasoning: Make Legal happy
20. Display of password expiration
    Reasoning: Feedback to user to let them know how much time is left with their current password. Though this is displayed at a prompt asking the user if they want to change their password, many answer no without really reading the message. The logon splash provides a good opportunity to emphasize this information while logon completes
21. Mapping of drives based upon group membership and other criteria
    Reasoning: This is one of the major reasons for having logon scripts
22. Setting up of printers
    Reasoning: This is one of the major reasons for having logon scripts
23. Setting of environment variables that will persist for just the user session and those that persist at the machine level
    Reasoning: The default environment variables are very helpful but others, such as site location, are conspicuously missing. This and others can be easily added to machine and/or user session environment variables. These can then be used as needed in your environment
24. Ability to dynamically turn off parts of the logon scripts that should not run based upon varying criteria
    Reasoning: Certain groups are very sensitive about there environments that they run their systems in, such as developers. To be able to easily bypass those parts of the code allows for maximum logon script flexibility
25. Modularization of logon script code so that other people may maintain the parts that they are responsible for without affecting the whole
    Reasoning: Dealing with smaller code chunks at a time is much easier. Additionally an error in one code module is less likely to break the logon scripts when run at logon and can provide for more easy troubleshooting in the event of an error
26. Running of scripts locally on each machine
    Reasoning: This provides for better performance running logon scripts (generally) and also mitigates any file contention issues that might be incurred by directly running scripts from the DC’s. Updating of logon script files on the servers can be performed at any time
27. Support of test and production branches of code and, if needed, any other number of branches
    Reasoning: It is imperative to have a means to develop and test your logon script changes prior to placing them into production
28. Leveraging of Windows Active Directory SYSVOL automatic replication
    Reasoning: With multiple sites with AD controllers in those sites, replicating files is automatic across sites. This combined with AD aware clients ensures that user logons will access the logon script files on the server that is closest to them thereby minimizing logon time
29. Ability to provide a means by which to install software and make configuration changes for users that logon with credentials that have local Administrator privileges
    Reasoning: This allows for standardization of the desktop and server platforms. For instance: a list of standard software to install on all newly built servers allows for standardization of server builds at first logon to the domain

This is the first post of what will likely be a long series of posts regarding logon scripts in an Active Directory 2003 environment. In this series of posts I plan on laying out the design criteria and actual design, accompanied by ample technical discussion, examples, and lessons learned.

The environment that this series comes out of is on containing 350 Windows servers from versions 2000 to 2008 and workstations from versions 2000 to Windows 7. The logon scripts will support Windows NT and Windows 9x with some tweaking as those were environments that were originally supported when we first implemented Active Directory 2003. Our environment also supports 140 retail stores, each with an AD 2000 domain controller, multiple sites, and multiple domains.

As I am a lazy administrator, if you ask questions I will try to answer them but may not be as timely as you might like - especially if questions would require troubleshooting in a test or production environment. But, if I have a ready answer to your questions I will answer them as soon as I can.

My next post will list the design criteria for the environment that I outlined above.