This is a quick blog post for a fun PowerShell script I got to write today.  My client asked me to make a listing of all instances of a particular workflow currently running on one of our SharePoint farms.  Since we have dozens of SharePoint lists spread out across numerous sub-sites on this farm I decided to tackle the request with PowerShell.

Here is a quick overview of what the scrip accomplishes.  First I get a reference to the site collection in question.  Next I get the workflow template from the name of the workflow I’m checking for.  Next I search all webs within the site collection and all lists within each web.  I filter the lists for any workflow associations with a BaseId matching my workflow template Id while also having at least 1 running instance.  Once I know there are running instances on this list I can then loop through all items in the list checking for workflows that are in the “Running” state.  I then output the SPWeb name, SPList name, and SPListItem name into a delimited output.

On a side note you may notice that I use $($variable.property) in my “write-output…” command.  I do this so that the property values are evaluated first before being passed to the the output stream.  If you attempt $variable.property you’ll most likely end up with a default value for $variable (typically ToString()) followed by “.property” which is not the intended result.

Download Script

Click here for a copy of this script off my SkyDrive.

*Note: As I’m currently very busy with SharePoint Saturday Columbus tasks this script is just in draft form so no recursive traversal of site hierarchy, input parameters, comments, etc.

$workflowNameToCheck = "My Sample Workflow"

$url = "http://SharePointDemo"

$spSite = new-object Microsoft.SharePoint.SPSite($url)

$spWeb = $spSite.OpenWeb()

$workflowBase = $spweb.WorkflowTemplates | where {$_.Name -eq $workflowNameToCheck}

$spWeb.Dispose()

foreach($spWeb in $spSite.AllWebs)

{

    for($i = 0; $i -lt $spWeb.Lists.Count; $i++)

    {

        $spList = $spweb.Lists[$i]

        $assoc = $spList.WorkflowAssociations | where {$_.BaseId -eq $workflowBase.Id.ToString() `

                            -and $_.RunningInstances -gt 0}

    if($assoc -ne $null)

        {

        foreach($item in $spList.Items)

            {

                if(($item.Workflows | where {$_.InternalState -eq "Running"}) -ne $null)

                {

                    write-output "$($spWeb.Name) | $($spList.Title) | $($item.Name)"

                }

            }

        }

    }

    $spWeb.Dispose()

}

$spSite.Dispose()

Conclusion

This script (very much in draft form) checks for running instances of a given workflow within a site collection.  After writing this script today I felt that this is probably a common search for some people so I hope you can glean some useful information from it.  If you find it useful or have any questions feel free to let me know.  Enjoy!

-Frog Out

Next time you fire up PowerShell to work with the SharePoint API make sure you launch the proper bit version of PowerShell.  Last week I had an interesting error that led to this blog post.  Travel back in time a little bit with me to see where this 32 vs. 64 bit debate started.

History

Ever since the first pre-beta bits of Office 2010 landed in my lap I have been questioning whether it’s better to run 32 or 64 bit applications on a 64 bit host operating system.  In relation to Office 2010 I heard a number of arguments for 32 bit including this link from the Office 2010 Engineering team.  Given my typical usage scenarios 32 bit seemed the way to go since I wasn’t a “super RAM hungry” Excel user or the like.

The Problem

Since I had chosen 32 bit Office 2010, I tried to stick with 32 bit version of other programs that I run assuming the same benefits and rules applied to other applications.  This is where I was wrong.  Last week I was attempting to use 32 bit PowerShell ISE (Integrated Scripting Environment) on a 64 bit WSS 3.0 server.  When trying to reference the 64 bit SharePoint DLLs I got the following errors about not being able to find the web application.

I have run into these errors when I have hosts file issues or improper permissions to the farm / site collection but these were not the case.  After taking a quick spin around the interwebs I ran across the below forum post comment and another MSDN forum reply that explained the error.  Turns out that sometimes it’s not possible to run 32 bit applications against a 64 bit OS / farm / assembly / etc.

…the problem could also be because your SharePoint is 64-Bit but your app is running in 32-bit mode

I quickly exited 32 bit PowerShell ISE and ran the same code under 64 bit PowerShell ISE.  All errors were gone and the script ran successfully.

Conclusion

The rules of 32 vs. 64 bit interoperability do not always apply evenly across all applications and scenarios.  In my case I wasn’t able to run 32 bit PowerShell against 64 bit SharePoint DLLs.  I’m updating all of my links and shortcuts to use 64 bit PowerShell where appropriate.  I’m quite surprised it has taken me this long to run into this error, but sometimes blind luck is all that keeps you from running into errors.  Lesson learned and hopefully this can benefit you as well.  Happy SharePointing all!

-Frog Out

Links

http://blogs.technet.com/b/office2010/archive/2010/02/23/understanding-64-bit-office.aspx

http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/a732cb83-c2ef-4133-b04e-86477b72bbe3/

http://stackoverflow.com/questions/266255/filenotfoundexception-with-the-spsite-constructor-whats-the-problem