Sharepoint has two state service commands that threw me for a loop

first there is get-SPSessionStateService
then there is get-SPStateServiceApplication

Here’s an article from MSDN that talks about the differences
http://blogs.msdn.com/b/markarend/archive/2010/05/27/using-session-state-in-sharepoint-2010.aspx

In Central Admin->Manage Service Applications these show up as follows:

Get-SPSessionStateService -> shows as type “SharePoint Server ASP.NET Session State Service”
Get-SPStateServiceApplication-> shows as type “State Service” and hopfully “State Service Proxy”

While you can easily delete both from Central admin, you can create neither of them from the service applications page.

Creating a new SPStateServiceApplication (and proxy) is relatively easy: 3 lines of powershell:

# from  http://technet.microsoft.com/en-us/library/ee704548.aspx
$serviceApp = New-SPStateServiceApplication -Name ""
New-SPStateServiceDatabase -Name "" -ServiceApplication $serviceApp
New-SPStateServiceApplicationProxy -Name "" -ServiceApplication $serviceApp -DefaultProxyGroup

Creating a new SPSessionStateService, on the other hand is a little more involved…

How do I know?

I’m glad you asked….

I ran into an issue where an access report would not display because “session state is not turned on” it didn’t say which one, and through some trial and error, I now understand it was likely looking for the service returned by get-SPSessionStateService.

For me that returned a blank line with no database entry so I thought I’d be best to delete it and recreate it from scratch.

I was wrong.

While deleting and recreating the SPStateServiceApplication is easy, the SPSessionStateService was not easily done in SP2010 with the included powershell commands.

Fortunately I found this article: http://ikarstein.wordpress.com/2010/12/14/error-while-enabling-session-state-service-on-sharepoint-2010/ Which had the steps to recreate the service manually.

I enabled the ASP.Net state windows service, then followed the article above, stopping about half way through, before the provisioning part.

To Provision it, I used Enable-SPSessionStateService -DefaultProvision

Get-SPSessionStateService now returns a complete row, with a database server, and DB name, and ID and best of all Enabled = True

So to summarize my problem,
MS Access services reports needed “SPSessionStateService” which also uses the windows service “ASP.Net State Service”

In troubleshooting, I wasn’t aware of the difference between states so I deleted the “wrong” one in an attempt to reset it.
A little digging and I now have a better understanding of the issue and of the two different state services.

I hope this helps!

I needed to enable / configure BLOB caching on multiple sharepoint sites.

This is done by editing the web.config of each SharePoint site, on each SharePoint server.

I wrote this down and dirty script so I would not need to edit all the web.config’s by hand (I had about 20 web.configs to touch)

Note that since its just editing the web.config, we don’t need to run this in a SharePoint shell – I ran it from an ordinary PowerShell command prompt on my workstation.

The script:

Echo "Run this script under an admin account with rights to the servers being hit"

$dir = "\Serverc$inetpubwwwrootwssVirtualDirectories"
$currentDate = (get-date).tostring("mm_dd_yyyy-hh_mm_ss")
# loop through each subdirectory to find each sharepoint site.
foreach ($subdir in dir $dir)
{
   #  Here In my case, all my SharePoint sites had mydomain.com as part of the folder names,
   #  So the contains statement was an easy way to only touch the web.config's of actual SharePoint sites
   #  while leaving alone central admin and other non-SharePoint websites IIS had.

   if($subdir.Name.Contains("mydomain.com"))
   {
        $path = $dir + "" + $subdir.name + "Web.config"
        echo $path

        $backup = $path + "_$currentDate.bak"
        $xml = New-Object XML
        $xml.Load($path)
        $xml.Save($backup)
        $element = $xml.configuration.SharePoint.BlobCache
        echo $element
        $element.location = "X:BlobCache14"
        $element.enabled = "true"
        $element.maxSize = "5"
        echo $element
        $xml.Save($path) 
   }
}

Over on my old Blog, Basementjack.com, Remco de Groot commented that this isn’t the best way to change a web.config in SharePoint and he’s absolutely right!

He sent over a script from
http://blogs.technet.com/b/heyscriptingguy/archive/2010/09/14/use-powershell-to-script-changes-to-the-sharepoint-web-config-file.aspx

The article above does a great job of explaining the new script and is a must read. In summary, it uses SharePoint to make the change, and this is a huge help down the line if you ever need to add or replace a SharePoint server in the farm.

I’ll leave the original post’s code above for search engines and as an example of using XML with PowerShell. That said, if you’re here to enable Blob Cache, then definately head on over to the article above

This is a script that gets each sharepoint site on the farm, enumerates all the site collections and webs and dumps them to the screen as well as a CSV file.

The Current date and time is always appended to the file name so you don’t have to worry about wiping out previous results.

#getalluserseverywhere
Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue

$timestamp = get-date -format "yyyyMMdd_hhmmtt"
$filenameStart = "AllFARMUsers"
$logfile = ("{0}{1}.csv" -f $filenamestart, $timestamp)

$header = "type,user,group,weburl,webname"
$header | out-file -FilePath $logfile

$iissitelist = get-spwebapplication 
foreach($onesite in $iissitelist)
{

	foreach ($SiteCollection in $onesite.sites)
	{
		write-host $SiteCollection -foregroundcolor Blue	
		foreach ($web in $SiteCollection.Allwebs)
		{ 
			 write-host "    " $web.url $web.name "users:" -foregroundcolor yellow
			 # Write-host "        " $web.users | select name 
			 foreach ($userw in $web.users)
			 {
				#if ($userw -like "domain*")
				#{
					write-host "        " $userw -foregroundcolor white
					#$msg = ("{0},{1} user:{2}" -f $web.url,$web.name, $userw)
					$msg = ("RootUser,{0},-,{1},{2}" -f $userw, $web.url,$web.name) 
					$msg | out-file -FilePath $logfile  -append
				#  }
			   }


			 foreach ($group in $web.Groups)
			{
						Write-host "        " $web.url $group.name: -foregroundcolor green
				 foreach ($user in $group.users)
				 { 
					# if ($user -like "Domain*")
					 #{   
						  Write-host "            " $user -foregroundcolor white
						  #$msg = ("{0},{1},group:{2}, user:{3}" -f $web.url, $web.name, $group, $user)
						  $msg = ("GroupUser,{0},{1},{2},{3}" -f $user, $group, $web.url, $web.name)
						  $msg | out-file -FilePath $logfile  -append
					 #}
				 }
			}	
			$web.Dispose()
		}
	  
	}
}

I recently had a stuck timer job in our sharepoint farm.
It seemed like an easy thing for Powershell, but it turned out to be one step more complicated – I’m not sure why, but here’s the solution I used – thanks to Todd from the Vendor I was working on for providing the fix!

We can use the Cmdlet get-SPTimerJob to see all timerjobs in our sharepoint farm.

If we add a nice little where clause, we can limit the list to a single item:

Get-SPTimerJob | where {$_.name -like "Name of your stuck job"} 

Normally I’ve been able to assign the results to a variable

ie like this:

$badjob = Get-SPTimerJob | where {$_.name -like "Name of your stuck job"} 

Which works.
What didn’t work however was this:

$badjob.delete()

For some reason, I got an error that there was no delete method.
Weird.

So instead:

Get-SPTimerJob | where {$_.name -like "Name of your stuck job"} |fl
# I then read the ID from the output of the above (note I added | fl at the end) 
# and I copied and pasted it into this command:
$badjobTake2 = Get-SPTimerJob -ID (pasted the ID here)
$badjobTake2.Delete()  #this worked

I’m not sure what the difference is, maybe I even fat fingered it the first time..
but that’s how it got resolved.

The Script below will list the version status of every site in your farm.
Note that as the script is below, it only reports, you’ll need to uncomment 3 lines if you want it to make the changes.

It’s a good idea to run the script once or twice before you do that, so you have a log of what settings were.

Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue

$timestamp = get-date -format "yyyMMdd_hhmmtt"
$filenameprefix = "VersionScriptoutput"
$logfile = ("{0}_{1}.csv" -f $filenameprefix, $timestamp)

$header = "ListURL,Enabled"
$header | out-file -filepath $logfile

# tip - the script as is will pull every sharepoint site (at the IIS level) in your farm.
# if you want to filter this to a single IIS site,
# remove the # from the middle of the next line and enter your site's url

$iissitelist = get-spwebapplication # | where {$_.url -eq "https://www.yoursite.com/"}
foreach ($iissite in $iissitelist)
{
	foreach ($SiteCollection in $iissite.sites)
	{
		write-host $SiteCollection -foregroundcolor Blue
		foreach ($oneweb in $SiteCollection.allwebs)
		{
		   write-host $oneweb.url -foregroundcolor Green
		   #now this is is where we look at the lists
		   $lists = $oneweb.lists
		   foreach ($list in $lists)
		   {
			  if($list.EnableVersioning -eq $false)
			  {
				  write-host  "$($iissite.url)$oneweb/$list is a not using versions" -foregroundcolor yellow
				  $msg = "$($oneweb.url),$($list.rootfolder)"	
			      $msg | out-file -filepath $logfile -append
                    # note!
                    # if you actually want to make the changes, uncomment the next 3 lines!
				  #$list.Enableversioning = $true
				  #$List.MajorVersionLimit = 3
				  #$list.update()
			  }
			  else
			  {
				  Write-host  "$($oneweb.url)/$($list.RootFolder) has versions enabled! " -foregroundcolor green
				  $msg = "$($oneweb.url)/$($list.rootfolder),true"				  
                  $msg | out-file -filepath $logfile -append
			  }
		   } 
		}
	}
}