Setting Site Quota Templates using PowerShell

Once sites are created, it can be a challenge to change the quota template. Here’s a way to rip through your site collections and change the quota. In the script below, I grab the Web Application, and go through all the Site Collections, but filter on them using -Match. The trick is to first ensure you are using the Content Service associated with the web application.

   $TemplateName = "MyQuota"
$webAppName = "http://yourWebApp"
$webApplication = Get-SPWebApplication $webAppName
$sFilter = "$($webAppName)/MyPath*"
 
$TemplateName = "MyQuotaTemplate"
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$quotaTemplate = $contentService.QuotaTemplates[$TemplateName]
 
if ($quotaTemplate -ne $null)
{
$ss = $webApplication.Sites 
$sCount = $ss.count
for ($i =0; $i -lt $sCount; $i++)
{
    $site = $ss[$i];
    if ($site.url -match $sfilter)
    {
        try
        {
            $site.set_Quota($quotaTemplate)
            Write-Host "Set Quota for $($site.url)"
        }
        catch
        {
            Write-Host -ForegroundColor DarkRed "Error setting Quota for $($site.url)"
        }
    }
    $site.dispose()
}
}

Automating the Creation of Per-Location Views

SharePoint offers the capability of customizing the Views in Folders.  This can be done manually.  This article will show you how to automate the configuration of views for each folder in a document library.

Configuring Per-Location Views Manually

To configure Per-Location Views manually, one must have at least library designer privileges. First, go into Library Settings, then select Per-Location Views:

For any View configured for the location, it appears as a folder with a green mark, indicating a custom Per-Location view:

How SharePoint Stores Per-Location Views

SharePoint stores the per-location view information in XML within a specific property (“client_MOSS_MetadataNavigationSettings”) of the RootFolder object of the list.   Here’s how to extract this XML and save it to a file for examination:

$RF=$List.RootFolder

$RF.Properties["client_MOSS_MetadataNavigationSettings"] > "L:1 before.xml"

Let’s look into the XML and see how Views are stored in this special property.  First note below that Views are referenced by the View GUID, the relative View URL, as well as an Index.  Positive indexes are available Views.  Negative Indexes are hidden Views, and the 0 index is the default View:

The approach

The basic approach is to grab the XML described above, clean it up from any previous customization, and add folder nodes; and for each folder, add Views.

Step-by-Step, programmatically adding a Per-Location View

First, let’s grab the List, and Folder objects:

  $web=get-spweb http ://SharePoint/MyWeb $lists=$web.lists
$list=$lists["ListName"]
$Folders=$list.Folders
$ViewSet="All Documents,EMail,Claim View,LC View,UW View"
$ViewArr=$ViewSet.split(",")

We can always save the XML for reference:

 $RF.Properties["client_MOSS_MetadataNavigationSettings"] > "L:1 before.xml"

Now, let’s grab the Views object, the Root Folder object, and the per-location Views cast as XML:

 $Views=$list.Views
$RF=$List.RootFolder
$x=$RF.Properties["client_MOSS_MetadataNavigationSettings"]

Now let’s wipe out any previous per-location Views customizations.  We will simply remove all nodes in the Folder

$x.MetadataNavigationSettings.NavigationHierarchies.FolderHierarchy.removeall()

Anytime we want to examine the XML, we can output it to file, using the InnerXML:

$x.InnerXml > "L:1 after.xml"

Normally, we would grab the  XMLElement using $x.MetadataNavigationSettings.NavigationHierarchies.FolderHierarchy, but this returns a string for a null or initialized node.
So instead, we grab the parent (NavigationHierarchies), then select the underlying single nodes:

$NavHierNode = $x.MetadataNavigationSettings.NavigationHierarchies

$ViewSettingsNode = $NavHierNode.SelectSingleNode(“FolderHierarchy”)

I’ve created Folder Content Types, by inheriting from the Folder Content Type.  This approach allows Folders to hold useful metadata and be selectable by users on creation.  In this case, I use the Folder Content Type to determine the View.  You can make the choice instead on the folder URL or metadata.  I simply loop through all folders, and select the preferred default folder based on the location:

for ($i=0; $i -lt $FolderCount; $i++)
{
 $Folder=$Folders[$i]
 
 switch ($Folder.ContentType.name)
 {
  "Underwriting Folder"  { $DefaultViewName= "UW View"}
  "Claim Folder"   { $DefaultViewName= "Claim View"}
  "Policy Folder"  { $DefaultViewName= "UW View"}
  "Loss Control Folder" { $DefaultViewName= "LC View"}
  default   { $DefaultViewName= "All Documents"}
 }

I grab the actual view, but take care to fall back on All Documents if the View is not found:

 $View=$Views[$DefaultViewName];
 
 if ($View -eq $null)
 {
  Write-Host "View ($($DefaultViewName) not found, falling back to All Documents"
  $DefaultViewName= "All Documents"; # logic assumes this is always there
  $View=$Views[$DefaultViewName];
 }
 
Now, we want to make note of the folder details for use in building the XML.  As you recall there are three aspects to the View of interest: the GUID, ID and relative URL:
[sourcecode language="powershell"]
$FolderGuid=$Folder.UniqueId
 
 $FolderID= $Folder.id
 
 $FolderURL= $Folder.Url;

So let’s start with the folder entry in the XML, by creating a new folder node, and populating it’s attributes, and first element, for the default view:

 $NewFolderNode=$X.CreateElement("ViewSettings");
 $NewFolderNode.SetAttribute("UniqueNodeId",$FolderGuid);
 $NewFolderNode.SetAttribute("FolderId",$FolderID);
 
 $NewViewNode=$X.CreateElement("View");
 $NewViewNode.SetAttribute("ViewId",$View.id);
 $NewViewNode.SetAttribute("CachedName",$View.Title);
 $NewViewNode.SetAttribute("Index","0");  #0 forces view to be default
 $NewViewNode.SetAttribute("CachedUrl",$View.Url);
 $NewFolderNode.AppendChild($NewViewNode);

Finally, we can add all the other Views for the folder. Note we start the index from 1, after the 0 default view. Now’s where the array of Views created earlier comes into use. I always like starting with a comma separated list, converting these into an array for easy use. We make sure not to add the default View a second time:

 $Index=1; # we want in increment index for each view for sequence
 foreach ($ViewName in $ViewArr)
 {
  $View=$Views[$DefaultViewName];
  if ($View -eq $null)
  {
   Write-Host "View ($($DefaultViewName) not found, secondary view, skipping" #never do a continue within foreach!
  }
  elseif ($ViewName -ne $DefaultViewName) #make sure to skip adding the default view as a secondary view
  {
   $View=$Views[$ViewName];
 
   $NewViewNode=$X.CreateElement("View");
   $NewViewNode.SetAttribute("ViewId",$View.id);
   $NewViewNode.SetAttribute("CachedName",$View.Title);
   $NewViewNode.SetAttribute("Index",$Index.tostring());  #0 forces view to be default
   $NewViewNode.SetAttribute("CachedUrl",$View.Url);
   $NewFolderNode.AppendChild($NewViewNode);
   $Index++; #view sequence numbering
  }
 }

$ViewSettingsNode.AppendChild($NewFolderNode)
Finally, we save our XML.  Note both update() are required:

$RF.Properties["client_MOSS_MetadataNavigationSettings"]=$x.InnerXml.ToString();
$RF.Update()
$list.Update() #both property and List update are required

[/sourcecode ]

See: Technet reference
Let’s finally put it all together:
[sourcecode language=”powershell”]
$web=get-spweb href=”http ://SharePoint/MySite”
$lists=$web.lists
$list=$lists[“MyListName”]
$Folders=$list.Folders

$ViewSet=”All Documents,EMail,Claim View,LC View,UW View”
$ViewArr=$ViewSet.split(“,”)

$WipeFolderDefaults=$true; # This is optional

$Views=$list.Views
$RF=$List.RootFolder
#$x.get_Properties()
[xml][/xml] $x=$RF.Properties[“client_MOSS_MetadataNavigationSettings”]

if ($WipeFolderDefaults)
{
try #if it fails, it is because the node just isn’t there, which might mean no folders defined, which is fine.
{
$x.MetadataNavigationSettings.NavigationHierarchies.FolderHierarchy.removeall()
}
catch
{
write-host “nothing to wipe, we are good to go!”
}
}

$FolderCount=$Folders.count;
$NavHierNode = $x.MetadataNavigationSettings.NavigationHierarchies
$ViewSettingsNode = $NavHierNode.SelectSingleNode(“FolderHierarchy”) #grabs it as XMLNode, instead of string, if empty node
for ($i=0; $i -lt $FolderCount; $i++)
{
$Folder=$Folders[$i]
switch ($Folder.ContentType.name)
{
“Underwriting Folder” { $DefaultViewName= “UW View”}
“Claim Folder” { $DefaultViewName= “Claim View”}
“Policy Folder” { $DefaultViewName= “UW View”}
“Loss Control Folder” { $DefaultViewName= “LC View”}
default { $DefaultViewName= “All Documents”}
}

$View=$Views[$DefaultViewName];
if ($View -eq $null)
{
Write-Host “View ($($DefaultViewName) not found, falling back to All Documents”
$DefaultViewName= “All Documents”; # logic assumes this is always there
$View=$Views[$DefaultViewName];
}

$FolderGuid=$Folder.UniqueId
$FolderID= $Folder.id
$FolderURL= $Folder.Url;

$NewFolderNode=$X.CreateElement(“ViewSettings”);
$NewFolderNode.SetAttribute(“UniqueNodeId”,$FolderGuid);
$NewFolderNode.SetAttribute(“FolderId”,$FolderID);

$NewViewNode=$X.CreateElement(“View”);
$NewViewNode.SetAttribute(“ViewId”,$View.id);
$NewViewNode.SetAttribute(“CachedName”,$View.Title);
$NewViewNode.SetAttribute(“Index”,”0″); #0 forces view to be default
$NewViewNode.SetAttribute(“CachedUrl”,$View.Url);
$NewFolderNode.AppendChild($NewViewNode);
$Index=1; # we want in increment index for each view for sequence
foreach ($ViewName in $ViewArr)
{
$View=$Views[$DefaultViewName];
if ($View -eq $null)
{
Write-Host “View ($($DefaultViewName) not found, secondary view, skipping” #never do a continue within foreach!
}
elseif ($ViewName -ne $DefaultViewName) #make sure to skip adding the default view as a secondary view
{
$View=$Views[$ViewName];

$NewViewNode=$X.CreateElement(“View”);
$NewViewNode.SetAttribute(“ViewId”,$View.id);
$NewViewNode.SetAttribute(“CachedName”,$View.Title);
$NewViewNode.SetAttribute(“Index”,$Index.tostring()); #0 forces view to be default
$NewViewNode.SetAttribute(“CachedUrl”,$View.Url);
$NewFolderNode.AppendChild($NewViewNode);
$Index++; #view sequence numbering
}
}

$ViewSettingsNode.AppendChild($NewFolderNode)

}

#$x.InnerXml > “L:PowerShellPer Location Views2a.xml”

$RF.Properties[“client_MOSS_MetadataNavigationSettings”]=$x.InnerXml.ToString();
$RF.Update()
$list.Update() #both property and List update are required

Gradual Site Collection Deletion

I had a mission to achieve overnight; move 28 site collections into a new managed path, as well as rename the 28 associated content databases.   Pretty straightforward to do, and to script in advance to run in stages:

1. Backup site collections
2. Delete site collections
3. Dismount content databases
4. Rename content databases and shuffle around underlying storage including FILESTREAM RBS location
5. Create the new managed path; reset of IIS
6. Remount 28 content DBs
7. Delete the old managed path
8. Restore the 27 content databases (this is where tinkling glass is heard, followed by painful silence)

After enough jolt cola to get that turtle to beat the hare fair and square, I got to the bottom of the problem.  First the problem.  The site collections could not be restored into their original database, as the site collection purportedly already existed there.  Even though it was deleted.

By midnight I gave up, and did the 28 Restore-SPSite into any random content databases, tossing organization and structure to the winds (temporarily), knowing I’ve got gads of available storage, knowing once I got to the bottom of the issue, a simple set of move-spsite commands would set things right.  No, I don’t like randomness, but I also like a few winks of sleep and happy users…

Now the cause.  I’m running SharePoint 2010 SP1, which has the ability to recover deleted site collections (not through the UI, but only through PowerShell).  I used the -gradualdelete option, thinking I would be nice and gentle with a production farm.  Here’s a sample of my delete commands, where I also disable prompting:

 Remove-spsite  href="http ://SharePoint/div/clm/int/A/"  -confirm:$false -gradualdelete

Here’s the kicker.  After the delete, the site collection is indeed still there.   It sticks around actually for the duration of the the Recycle Bin duration (default 30 days).  There’s one good way to see, let’s dive into the forbidden content database, and have a peek:

 SELECT [DeletionTime]
,[Id]
,[SiteId]
,[InDeletion]
,[Restorable]
FROM [Content_mydivision_a].[dbo].[SiteDeletion]
where (Restorable=1)

Restorable=1 indicates this site collection could be restored.

The solution?  Well, it’s not the recycle bin job, that has no effect on this.  There is a gradual delete job at the web application level, but that won’t help us either; at least not just yet.  First you have to use the remove-spsite CmdLet to remove each site permanently.  Here’s the syntax:

remove-spdeletedsite f5f7639d-536f-4f76-8f94-57834d177a99 -confirm:$false

Ah, you don’t know your Site Collection GUIDs by heart? well, me neither, I prefer more useful allocation of brain cells, so here’s the command that will give you the Site Collection GUIDs that have been (partially) deleted:

  get-spdeletedsite -webapplication "http ://SharePoint/"

So, you got your partially deleted GUIDs, you diligently did a remove-spdeletedsite for each, but the Restore-SPSite still will not work.  Now’s the time to run the handy-dandy Gradual Delete timer job for your web application, in Central Admin, Monitoring.  First thing you might notice is the job is taking a bit of time to run.  That’s good, it’s doing something for you, and actually triggering the Content DB Stored Procedure called proc_DeleteSiteCoreAsync.  It actually deletes in batches.

Here’s how to wipe out all these mildly annoying site collections from your recycle bin for a web application:

  get-spdeletedsite -webapplication "http://ma-srv-sp10/" | Remove-SPDeletedSite

At this point your Restore-SPSite will work to your target content database, and if you played SharePoint Roulette like me and restored to a random location, a move-SPSite will make fast work of putting things where they should be.

More information on the Gradual Deletion Timer Job can be found in this Technet Article by Bill Baer

Reporting on Anonymous surveys

SharePoint enables the creation of anonymous surveys, but how anonymous are they?   If you want a truly anonymous survey, then you will want to create a new web application that allows anonymous access without authentication.  Here’s a TechNet article with some good guidance on doing that.

If you create an anonymous survey in a web application with authentication, the user information is captured, but is hidden to users, and even within the .NET Object model.   SharePoint will gladly create audit logs of access that can expose the survey use.    Note that a site administrator with Full Control can change a survey to non-anonymous and expose the users.

Using PowerShell, we can temporarily expose the users, report on them, then restore the anonymity.  This is useful when needing to chase down non-respondents to a survey, without exposing which survey was completed by whom.  Here’s the PowerShell I wrote to achieve this.  The console output is structure to allow text-to-column conversion or CSV reading in Excel, then easily pivot-table reporting on the results:

 $web=Get-SPWeb href="http ://SharePoint/sites/EXEC
$lists=$web.Lists;
Write-Host "List or Survey,Creator of List or Survey,List Creation Time,List Edit Time,Person completing Survey,Modified Date of list entry"
for ($i=0; $i -lt $lists.count; $i++)
{
$list=$lists[$i]
if (!$list.get_ShowUser())
{
$reversion=$true;
$list.set_ShowUser($true)
$list.update()
}
else
{
$reversion=$false;
}
 
foreach ($item in $list.Items)
{
Write-Host "$($list.title), $($List.get_author()) , $($List.LastItemModifiedDate), $($List.Created), $($item['Author']),$($item['Created'])"
}
if ($reversion)
{
$list.set_ShowUser($false)
$list.Update();
}
 
}

During the running of the script, the survey becomes non-anonymous briefly, so do consider only running this off-hours
[/av_textblock]