mylifeinaminute.com

The Problem

In it’s default configuration, SharePoint (2007 and 2010) will delete workflow associations after 60 days (e.g. the information found on the Workflow Status page). There are times when you may want to alter this functionality and retain the association for a longer period of time.

In SharePoint 2007, the recommendation from Microsoft (per TechNet), is to disable the Workflow Auto Cleanup timer job. The Workflow Auto Cleanup timer job is a web application scoped timer job. As such, disabling the job is often not the optimal solution; as disabling the job will ensure that cleanup is not occurring for all of the site collections within the web application for which the timer job was disabled.

The Solution

Thankfully, there is a property (SPWorkflowAssociation.AutoCleanupDays) that is exposed with the workflows associated with a given list/content type. And once again, PowerShell comes to the rescue, giving us the ability to manipulate the cleanup days at a more granular level. This ensures that we do not disable the timer job for an entire web application.

Presented as two functions, we can manipulate the workflow association settings for either the workflows associated with a list or the workflows associated with a content type attached to a list.

Set-SPListWorkflowAssocationCleanup

The following function allows us to set the AutoCleanupDays for all of the workflows associated with a given list.

Set-SPListWorkflowAssocationCleanup -WebUrl "http://intranet" -ListName "Shared Documents" -CleanupDays 365 -ReportOnly:$false

function Set-SPListWorkflowAssocationCleanup {
    param (
        [string] $WebUrl = $(Read-Host -prompt "Enter a Url"),
        [string] $ListName = $(Read-Host -prompt "Enter a List Name"),
        [int32] $CleanupDays = $(Read-Host -prompt "Enter the number of Cleanup Days"),
        [switch] $ReportOnly = $true
        )        

    $web = Get-SPWeb $WebUrl;
    if ($web -eq $null) {
        Write-Error -message "Error: Web Not Found" -category InvalidArgument
    } else {
        $list = $web.Lists[$ListName];
        if ($list -eq $null) {
            Write-Error -message "Error: List Not Found" -category InvalidArgument
        } else {
            [Microsoft.SharePoint.Workflow.SPWorkflowAssociation[]] $wfaMods = @();
            foreach ($wfa in $list.WorkflowAssociations) {
                $message = "Found Workflow Association for " + $wfa.Name + " with AutoCleanupDays set to " + $wfa.AutoCleanupDays
                Write-Verbose -message $message -verbose

                if ($ReportOnly -eq $false) {
                    $wfa.AutoCleanupDays = $CleanupDays;
                    $wfaMods = $wfaMods + $wfa;
                }
            }

            if ($ReportOnly -eq $false) {
                foreach ($wfa in $wfaMods) {
                    $message = "Setting AutoCleanupDays for " + $wfa.Name + " to " + $CleanupDays
                    Write-Verbose -message $message -verbose
                    $list.WorkflowAssociations.Update($wfa);
                }
            }
        }
    }
}

Set-SPListContentTypeWorkflowAssocationCleanup

The following function allows us to set the AutoCleanupDays for all of the workflows associated with content type for a given list.

Set-SPListContentTypeWorkflowAssocationCleanup -WebUrl "http://intranet" -ListName "Shared Documents" -ContentTypeName "Document Content Type" -CleanupDays 365 -ReportOnly:$false

function Set-SPListContentTypeWorkflowAssocationCleanup {
    param (
        [string] $WebUrl = $(Read-Host -prompt "Enter a Url"),
        [string] $ListName = $(Read-Host -prompt "Enter a List Name"),
        [string] $ContentTypeName = $(Read-Host -prompt "Enter a Content Type Name"),
        [int32] $CleanupDays = $(Read-Host -prompt "Enter the number of Cleanup Days"),
        [switch] $ReportOnly = $true
        )        

    $web = Get-SPWeb $WebUrl;
    if ($web -eq $null) {
        Write-Error -message "Error: Web Not Found" -category InvalidArgument
    } else {
        $list = $web.Lists[$ListName];
        if ($list -eq $null) {
            Write-Error -message "Error: List Not Found" -category InvalidArgument
        } else {
            $ct = $list.ContentTypes[$ContentTypeName];
            if ($ct -eq $null) {
                Write-Error -message "Error: Content Type Not Found" - category InvalidArgument
            } else {
                [Microsoft.SharePoint.Workflow.SPWorkflowAssociation[]] $wfaMods = @();
                foreach ($wfa in $ct.WorkflowAssociations) {
                    $message = "Found Workflow Association for " + $wfa.Name + " with AutoCleanupDays set to " + $wfa.AutoCleanupDays
                    Write-Verbose -message $message -verbose

                    if ($ReportOnly -eq $false) {
                        $wfa.AutoCleanupDays = $CleanupDays;
                        $wfaMods = $wfaMods + $wfa;
                    }
                }

                if ($ReportOnly -eq $false) {
                    foreach ($wfa in $wfaMods) {
                        $message = "Setting AutoCleanupDays for " + $wfa.Name + " to " + $CleanupDays
                        Write-Verbose -message $message -verbose
                        $ct.WorkflowAssociations.Update($wfa);
                    }
                }
            }
        }
    }
}

Conclusion

By manipulating the workflow associations for a list at the list/content type level the default configuration of a SharePoint farm can be retained (e.g. Workflow associations removed after 60 days) and in those cases where there is a business need, the workflow associations can be maintained for a longer period of time.

Reference

• SPWorkflowAssociation.AutoCleanupDays Property
• SharePoint Timer job reference (Office SharePoint Server)
• Timer job reference (SharePoint Server 2010)
• SharePoint Workflow History “Disappears”

In the SharePoint 2010 Information Worker, the FASTSearchCert deployed in the image expired in April 2011 and needs to be updated.

The following script (credit to Bryan Hart) will update the certicate in a single elevated PowerShell prompt.

###################################
# Apply Certificate to FAST
###################################
write-host "Applying Certificate to FAST" -ForegroundColor Yellow

Add-PSSnapin AdminSnapIn
Add-PSSnapin Microsoft.FASTSearch.PowerShell
Add-PSSnapin Microsoft.SharePoint.PowerShell

stop-service FAST*

$installerdir = $env:FASTSEARCH + "installer\scripts"

cd $installerdir

$pw = ConvertTo-SecureString -AsPlainText -force pass@word1

.\ReplaceDefaultCertificate.ps1 -generateNewCertificate $true -certificatePassword $pw

$cert = @(dir cert:\LocalMachine\My -recurse | ? { $_.Subject -eq 'CN=FASTSearchCert' })[0]

$thumb = $cert.Thumbprint

Start-service FAST*

.\SecureFASTSearchConnector.ps1 -certThumbprint $thumb -ssaName "FASTContent" -username "contoso\administrator"

Reference

• Remember to give your SharePoint 2010 Information Worker Virtual Machine a fresh certificate

I recently had an interesting situation come up where a Governance committee (you have one right?) decided to alter their document versioning guidelines. The current policy dictated that all documents had both major/minor versioning. The new policy stated that the organization would be moving to a major versioning only scheme.

With thousands of document libraries in an established farm, the prospect of visiting thousands of List Settings pages was not at all appealing. PowerShell to the rescue.

The Script

The following script accepts a parent web and enumerates all of its children (optional), altering the libaries that match the criteria “Not a System/Style/Hidden library” and “has minor versioning currently enabled”. The matching libraries are updated to force document checkouts and accept an unlimited numer of major versions (Governance decision, no listening to reason there).

function Reset-SPDocumentLibaries {
	param (
		[string] $WebUrl = $(Read-Host -prompt "Enter a Url"),
        [switch] $ProcessChildren
	) 

	$web = Get-SPWeb $WebUrl;

	ProcessWeb $web $ProcessChildren;
}

function ProcessWeb($web, $processChildren) {

	Write-Host "Processing Web",$web.Title,"(",$web.Url,")" -foregroundcolor "Green";

	$lists = @($web.Lists | Where-Object { ($_.BaseType -eq "DocumentLibrary") -and ($_.BaseTemplate -eq "DocumentLibrary") -and ($_.IsSiteAssetsLibrary -eq $false) -and ($_.EnableMinorVersions -eq $true) -and ($_.Hidden -eq $false) -and ($_.Description -notlike "*system*") -and ($_.Description -notlike "*style*") })

    if ($lists.Count -gt 0) {
    	foreach ($list in $lists) {
    		if ($list.Title.Length -gt 0) {
    			Write-Host "   Processing List",$list.Title -foregroundcolor "Green";

    			$list.EnableVersioning = $true;
    			$list.EnableMinorVersions = $false;
    			$list.MajorVersionLimit = 0;
    			$list.ForceCheckout = $true;

    			$list.Update();
    		}
    		else {
    			Write-Host "   Invalid List Encountered" -foregroundcolor "Red"
    		}
    	}
    } else {
        Write-Host "   No lists matching filter were found" -foregroundcolor "Red"
    }

    if ($processChildren) {
    	foreach ($subWeb in $web.Webs) {
    		ProcessWeb $subWeb $processChildren
    	}
    }
}

A recent client engagement had us flipping back and forth between the v3 and v4 UI (Visual Upgrade) for a number of site collections in a given content database.

The PowerShell function outlined below allows for setting the UIVersion on all of the site collections and sites in a given content database in one shot.

function Set-SPUIVersion(
    [string]$dbName = $(Read-Host -prompt "Content Database Name"),
    [int32]$uiVersion = $(Read-Host -prompt "UI Version"))
    {
	$db = Get-SPContentDatabase $dbName

	foreach ($s in $db.Sites) {
		foreach ($w in $s.AllWebs) {
			$w.UIversion = $uiVersion;
			switch ($uiVersion) {
				3 { $w.UIVersionConfigurationEnabled = $true; }
				4 { $w.UIVersionConfigurationEnabled = $false; }
			}
			$w.Update();
		}
	}
}