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