Slides and Scripts from DogFood Conference 2014

   I was pleased to once again speak at the Dog Food Conference here in Columbus, OH.  I believe this is the 3rd year that I have spoken and the 4th or 5th year that I have attended.  The venue has moved to a more spacious location which definitely helped with giving attendees, speakers, and vendors more room to spread out,  I was especially happy to meet up with dozens of previous customers and co-workers at the conference.  This really is a great mix of audiences (developers, IT pros, and business users), customer segments, and topics (SharePoint, .Net, PowerShell, BI, ALM, and more).

   Thanks to everyone who attended my session at the very end of the last day of the conference.  We had a number of good side discussions and questions throughout the presentation.  Below are my slides and scripts.


Demo PowerShell Scripts




      -Frog Out

Slides and Scripts from SharePoint Cincy 2014

   I was pleased to present at SharePoint Cincy again for the third year.  Geoff and all the organizers do a great job.  My presentation this year was “PowerShell for Your SharePoint Tool Belt”.  Below are my slides and demo scripts.  Thanks for all who attended, I hope you found something that will be useful for you in your work.


Demo PowerShell Scripts




      -Frog Out

PowerShell Script To Determine If SharePoint List Uses InfoPath Forms

   Recently I had a request from a customer to find which SharePoint 2010 / 2013 lists are using InfoPath forms for their data entry (also known as enterprise forms for a SharePoint list).  In this post I will show you a PowerShell script to determine if a SharePoint list is using InfoPath forms.



  As you may have heard, InfoPath as a product will not be receiving any future releases (see InfoPath roadmap update blog post).  Being able to find SharePoint lists using InfoPath forms may be useful to you now.



   Special thanks goes out to Joe Rodgers (fellow PFE at Microsoft) who helped me narrow down the specific properties to look at.  The property that we want is not at the base of the SPList properties nor on the SPList.Forms properties like I had hoped.  Instead you will need to dig a few levels down.  I found the property at SPList.ContentTypes[0].ResourceFolder.Properties[“_ipfs_infopathenabled”].  If this setting is true then your list is using InfoPath forms for data entry.  If it is false then it is using out of the box SharePoint forms.


Add-PSSnapin microsoft.sharepoint.powershell 
$webURL = <Your Site URL> 
$documentLibraryName = <name of document library> 

$web = Get-SPWeb 
$list = $web.Lists[“$documentLibraryName”] 
$isUsingInfoPath = $list.ContentTypes[0].ResourceFolder.Properties[“_ipfs_infopathenabled”] 
Write-Output $isUsingInfoPath 



   This script will determine if a single SharePoint list is using InfoPath forms or not.  You could easily expand this to work with multiple lists or sites (similar to my PowerShell Script to Determine Number of Files in SharePoint 2010 or 2013 Document Libraries).  Feel free to adapt the above snippet in this post to your needs but please attribute rights if you republish.


      -Frog Out

PowerShell Script to Limit SharePoint Site Templates Available

   I had a customer request recently to limit the which site templates were available to end users to create subsites.  Below is a short PowerShell script to do just that.



   If you are using a Publishing Site you can restrict the available site templates by going to Site Settings –> Look & Feel and clicking on Page Layouts and Site Templates (see following screenshot).  If you are not on a Publishing Site then there is not an easy (supported) way to accomplish this through out of the box means.




   The SPWeb class has methods GetAvailableWebTemplates and SetAvailableWebTemplates that can be used in conjunction with each other to get the current list of templates and then filter down to only the desired templates.  The filtered down results can then be set and updated on the SPWeb.  A version of this script can be downloaded from the TechNet Script Repository: Limit available web templates for a SharePoint site.

Note:  Be sure to modify the “<URL of site>” to your site’s URL and also change which templates to keep (line 2).


# array of template names (not titles) to keep 
$templateNamesToKeep = “STS#0”,“PROJECTSITE#0”,“BLOG#0” 

Start-SPAssignment -Global 
$web = Get-SPWeb <URL of site> 
# get the existing web templates from the site that will be filtered down 
# 1033 is the locale id for English US (en-us), be sure to change to your locale 
$existingWebTemplates = $web.GetAvailableWebTemplates(1033) 
$newWebTemplates = New-Object “System.Collections.ObjectModel.Collection[Microsoft.SharePoint.SPWebTemplate]” 
# filter existing web templates and only keep if in the list of template names to keep 
$newWebTemplates = $existingWebTemplates | Where-Object {$ -in $templateNamesToKeep} 
$web.SetAvailableWebTemplates($newWebTemplates, 1033) 
Stop-SPAssignment -Global 

   Before you run the script you will see the original list of available web templates when creating a subsite.



   After you run the script you will now see only the templates which you listed in the templates to keep.



   If you need to reset the list of available web templates you can execute the AllowAllWebTemplates method on the SPWeb object.



   I had run across a few other samples for limiting web templates that involved modifying out of the box SharePoint files (changes which may be overwritten by future updates or patches, and thus not recommended).  This process of using the SetAvailableWebTemplates() method appears to be a bit more safe and supported.


      -Frog Out

Guest Blog Post on Hey Scripting Guy Blog – STSADM Replacement

   Quick blog post here to let you know that I wrote a guest blog post for Ed Wilson (The Microsoft Scripting Guy) over on the Hey Scripting Guy blog.  The post is titled “Weekend Scripter: Using PowerShell to Replace STSADM” and covers some research I did into replacing the functionality of the “STSADM –o enumallwebs” command with PowerShell.  Feel free to give it a read and let me know if you have any feedback or comments.   Have a great end of this 2013 year.


      -Frog Out



Weekend Scripter: Using PowerShell to Replace STSADM

PowerShell Script to Workaround No Data in SharePoint 2013 Usage Reports

   Over the past few months I’ve had 2 customers that have run into an scenario where the SharePoint 2013 web analytics usage reports have no data (all zeroes) in the reports.  While working with some brilliant Microsoft escalation engineers (thanks Anthony and Jason) we were able to run some PowerShell scripts that added receivers to start data showing again on the following day.  Since I haven’t seen any posts on this as of yet I thought I would post a version of the PowerShell scripts we used.



    In SharePoint 2013 the search service application incorporates web analytics (which is a separate service application in SharePoint 2010).  Web analytics processes usage logs on the SharePoint machines and generates reports on a daily schedule.  These reports can be viewed for an individual site in the site settings under Site Collection Administration > Popularity and Search Reports.



   In the Popularity and Search Reports you can click on the Usage report which will launch an Excel workbook.



   What I found with 2 customers and one of my lab farms was that the Usage report contained all zeroes for data even though the customer (and me in my lab farm) had been using the site regularly with multiple accounts over the past few days.



   We analyzed the logging database and found that it had usage data, but the search analytics database did not.  (Note: do not directly query the search analytics database as that is unsupported as of the time this post was written.  See for more information.)  So it appeared the data in the logging database wasn’t being processed by the search service web analytics timer jobs.  After verifying that the timer jobs were indeed running the long road of PowerShell queries into the system began.  We finally used the below commands to arrive at what we believe to be the culprit for these customers.  Our findings follow the commands.


$aud = Get-SPUsageDefinition | where {$_.Name -like “Analytics*”} 
$aud | fl 

$prud = Get-SPUsageDefinition | where {$_.Name -like “Page Requests”}  
$prud | fl 
  • AnalyticsUsage usage definition had no Receivers defined
  • PageRequest usage definition had no Receivers defined



    Not having any Receivers defined also led to the EnableReceivers property to be set to false for both.



   The workaround in these scenarios was to manually create the Receivers.  The PowerShell commands to do so is below (slightly modified to check for empty receivers first).  Again this sample script is provided as-is with no warranty.  Do not run this in your environment without first testing.  This is not an official Microsoft approved script.  You can download a copy off my SkyDrive folder as well.


if((Get-PSSnapin -Name Microsoft.SharePoint.PowerShell) -eq $null) 
    Add-PSSnapin Microsoft.SharePoint.PowerShell 

$aud = Get-SPUsageDefinition | where {$_.Name -like “Analytics*”} 
# if analytics usage definition receivers is empty then manually add back receiver 
if($aud.Receivers.Count -eq 0) 
    $aud.Receivers.Add(“Microsoft.Office.Server.Search.Applications, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c”, “Microsoft.Office.Server.Search.Analytics.Internal.AnalyticsCustomRequestUsageReceiver”) 
# if analytics usage definition receiver is not enabled then enable it 
if($aud.EnableReceivers -eq $false) 
    $aud.EnableReceivers = $true 
$aud | fl 
$prud = Get-SPUsageDefinition | where {$_.Name -like “Page Requests”}  
# if page requests usage definition receivers is empty then manually add back receiver 
if($prud.Receivers.Count -eq 0) 
    $prud.Receivers.Add(“Microsoft.Office.Server.Search.Applications, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c”, “Microsoft.Office.Server.Search.Analytics.Internal.ViewRequestUsageReceiver”)  
# if page requests usage definition receiver is not enabled then enable it 
if($prud.EnableReceivers -eq $false) 
    $prud.EnableReceivers = $true 
$prud | fl 

   After the script has been run the output from the prior commands can confirm that Receivers have been created and the EnableReceivers property is set to true.



<Update 2013-08-09>

   The next step is to recycle the OWSTimer service (SharePoint Timer Service) on each server.  This ensures that the new receivers are properly picked up by the timer jobs.

</Update 2013-08-09> 

  Waiting one day the usage reports were now showing data.  (Note the below report was mocked up manually to show data as I did not have direct access to the customers’ reports, but this is consistent with what we had seen after the scripts were applied.)




   This is a strange scenario of no data in the usage reports when there is data in the logging databases.  I’ve run into it myself and with 2 customers, but when I tried to reproduce the scenario I couldn’t.  If anyone is facing this issue hopefully this process of manually creating the usage definition receivers and waiting 24 hrs is a workaround.  Let me know if you have seen this and if the workaround works for you.  Curious to learn more on it.


      -Frog Out