SharePoint Powershell Scripting: Iterating through a Site Collection to find all BLOBs that havent been modified in over a year

This request came about during a SharePoint/Metalogix StoragePoint requirements gathering session with a customer.  They wanted to know what the storage savings would be if they externalized ONLY files that havent been modified in over a year vs all files.  Metalogix has a great tool affectionately called the "BLOBulator" which will analyze Content DBs (and drill down further into Site Collections), however as a free tool, there isnt much customization when it comes to filtering in criteria for said externalizations.

So I decided to use Powershell to iterate through a site collection of my choosing and output into a csv file. I could then do a quick calculation on all the documents to get a total size.

This script works fine, except at the end it will throw an error on the dispose function.  If anyone can help resolve that, please feel free to leave a comment and I'll update my post.  This script can also be adjusted to run against an entire we application as well.

Add this code to a text document and rename it with a .ps1 extension:

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue 

function Get-OldDocuments([string] $SiteURL)

{

    $Site = Get-SPSite $SiteURL


                foreach ($SPWeb in $SPSite.AllWebs)

                   {

                    foreach ($SPList in $SPWeb.Lists) 

                      {

                        # Get Document Libraries

                        if ($SPList.BaseType -eq "DocumentLibrary") 

                         {

                            foreach ($item in $SPList.Items)

                              {

                                $data = @{

                                "Site" = $SPSite.Url

                                "Web" = $SPWeb.Url

                                "list" = $SPList.Title

                                "Item URL" = $item.Url

                                "Item Title" = $item.Title

                                "Item Created" = $item["Created"]

                                "Item Modified" = $item["Modified"]

                                "Size (KB)" = $item.File.Length/1KB

                                "Size (MB)" = $item.File.Length/1MB

                                }


                                # add files older than 1yr old

                                $expireDate = Get-Date 
$expireDate = $expireDate.AddYears(-1)

                                if($item["Modified"] -lt $expireDate)

                                {

                                    Write-Host($SPSite.Url +"/"+ $item.Url)

                                    New-Object PSObject -Property $data

                                }

                            }

                        }
}
                     $SPWeb.Dispose();

                    }

                  $SPSite.Dispose()   

                }


#call the function 

Get-OldDocuments "http://sharepoint.com/site" | Export-Csv -NoTypeInformation -Path C:\temp\OldDocuments.csv

"Save Site as Template" Option is Missing on Publishing Site in SharePoint 2013

At first glance, something appears to be wrong.  "Why cant you simply save the site as a template", I asked.  Perhaps Microsoft (in all it's infinite wisdom) decided to remove the "save a site as a template" feature by default with publishing sites.  That's okay, you can simply navigate to “_layouts/savetmpl.aspx” application page and save the site template, right?  Wrong!  This workaround does not work as expected in SharePoint 2013.

The url “_layouts/savetmpl.aspx” failed on the publishing site because by default in SharePoint 2013, “SaveSiteAsTemplateEnabled” is set as “false”.  Fortunately it's a very quick fix, simply change this switch to true in 3 simple steps!

1. Open the site in SharePoint Designer
2. Click Site Options from the ribbon
3. Modify the "SaveSiteAsTemplateEnabled" and change it from "False" to "True"

The option still wont be displayed in Site Settings, but you can now you can navigate to “http://sitename/_layouts/15/savetmpl.aspx” and you will see the Save Site as Template Page as expected.

That's All Folks!

Iterate Through All Site Collections Within a Web Application to Change The Site Collection Administrator

If you have many Site Collections in a single web application and you want to set or change the Primary or Secondary Site Collection Administrator without going through each and every one in Central Administration, below is the script you can save as a .ps1 file and run in Powershell.  This script uses (-SecondaryOwnerAlias) to set the Secondary Site Collection Administrator. Change it to (-OwnerAlias) at line 19 to set the primary site collection admin.

## Input Parameters ##
[CmdletBinding()]
Param(
[string]$WebAppUrl=(Read-Host "Please enter a Web Application URL (Example: http://intranet)"),
[string]$Account=(Read-Host "Please enter an account (Example: DOMAIN\Administrator)")
)
## Add SharePoint Snap-in ##
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
### No need to modify these ###
$WebApp = Get-SPWebApplication $WebAppUrl
$AllSites = $WebApp | Get-SPSite -Limit ALL

##The Script - no need to modify this section ##
## Start SP Assignment for proper disposal of variables and objects ##
Write-Host "Starting SP Assignment..." -ForegroundColor Green
Start-SPAssignment -Global
## Use a ForEach-Object loop and Set-SPSiteAdministration to set an entire web application ##
Write-Host "Adding $Account to $WebAppUrl as a Site Collection Administrator..." -ForegroundColor Yellow
$AllSites | ForEach-Object { Set-SPSite -SecondaryOwnerAlias $Account -Identity $_.url }
## End SP Assignment for proper disposal of variables and objects ##
Write-Host "Disposing of SP Objects.." -ForegroundColor Green
Stop-SPAssignment -Global
## Tell us it's done ##
Write-Host "Finished!" -ForegroundColor Green

How To Set SharePoint Managed Service Account Password with PowerShell

Here is the scenario where this would be important:

Issue Cause
-       During the course of regular SharePoint administration duties a deployment process was hung up.  From past experience and part of the standard procedures in such situation, a SharePoint 2010 timer service was restarted and a command was run to force deployment of pending jobs.
-       When the jobs were forced to run, several pending jobs that were not scheduled to run were inadvertently triggered. The job that caused the issues was the automatic password change on SharePoint 2010 managed accounts. This job is typically scheduled for the 7th of every month, but is queued and marked as pending.  As the password change job was queued as pending the force command kicked off the password changes.  These jobs did not successfully complete and while the passwords were generated and updated in Active Directory, SharePoint was not updated.
-       This resulted in a password mismatch between the password in Active Directory and the password that the Web and Service Application Identities were using to run the sites. Furthermore, once the cached credentials on the IIS servers were refreshed the applications were no longer available.

Issue Resolution
Once the source of the problem was identified Admins needed to manually change the passwords on the affected accounts and then update the passwords in SharePoint.  Since CA was not accessible, passwords needed to be changed with PowerShell:

$P7 = ConvertTo-SecureString "password" -asplaintext -force

Set-SPManagedAccount -Identity <account name> -ExistingPassword $P7

THAT WAS EASY! How to check which Site Template was used in SharePoint 2013

Don't mess with logging into the server and running powershell cmdlets.  Here is the SUPER EASY way to check which Site Template was used in SharePoint 2013:

1. Open your site in browser
2. Open any page
3. Right click on the page
4. Select view source
5. Search for: SiteTemplateID

List of Site Templates:
#0 - GLOBAL (SetupPath=global) - "Global template"
#1 - STS - "windows SharePoint Services Site", "Team Site", "Blank Site", "Document Workspace"
#2 - MPS - "Basic Meeting Workspace", "Blank Meeting Workspace", "Decision Meeting Workspace", "Social Meeting Workspace", "Multipage Meeting Workspace"
#3 - CENTRALADMIN - "Central Admin Site"
#4 - WIKI - "Wiki Site"
#7 - BDR - "Document Center"
#9 - BLOG - "Blog"
#20 - SPS (OBSOLETE) - "SharePoint Portal Server Site"
#21 - SPSPERS - "SharePoint Portal Server Personal Space"
#22 - SPSMSITE - "Personalization Site"
#30 - SPSTOC (OBSOLETE) - "Contents area Template"
#31 - SPSTOPIC (OBSOLETE) - "Topic area template"
#32 - SPSNEWS (OBSOLETE) - "News area template"
#33 - SPSNHOME (SubWebOnly) - "News Home template"
#34 - SPSSITES - "Site Directory area template"
#36 - SPSCOMMU (OBSOLETE) - "Community area template"
#38 - SPSREPORTCENTER - "Report Center Site"
#39 - CMSPUBLISHING (SetupPath=SiteTemplates\PUBLISHING) - "Publishing and Team Collaboration Site"
#40 - OSRV (SetupPath=SiteTemplates\OSRV) - "Shared Services Administration Site"
#47 - SPSPORTAL - "Corporate Intranet Site"
#50 - SRCHCEN - "Search Center"
#51 - PROFILES - "Profiles"
#52 - BLANKINTERNETCONTAINER - "Internet Presence Web Site"
#53 - BLANKINTERNET - "Publishing Site", "Press Releases Site", "Publishing Site"
#54 - SPSMSITEHOST - "MySite Host"
#90 - SRCHCENTERLITE (SetupPath=SiteTemplates\SRCHCENTERLITE) - "Search Center Lite"
#6221 - PWA (SetupPath=SiteTemplates\PWA) - "Project Web Access Site"
#6215 - PWS (SetupPath=SiteTemplates\PWS) - "Project Workspace"
#14483 - OFFILE - "Records Repository", "Records Repository"

SharePoint 2010 Admin Tip of The Day: Duplicate a large custom list on a single site for archive purposes

I was recently asked by a site admin to help with archiving a FY14 list.  They wanted to keep the list on the site, but use a subset of the content to create a new list called FY15.  They wanted to retain all the views, time stamps, etc.  The list was quite large.  It had over 4000 items and had too many columns, including lookups, calculations, multi-select and multi-line fields for me just to do a datasheet to datasheet copy or an excel export.  Of course this would also not retain the created by, date, etc, so it really wasnt a viable option.  The data was also too large to include the content with the 'save list as template' and duplicate it that way. So it was time for this guy to get creative!

The first thing I did was export the list to a file on the server.  At first, I was having problems with using powershell (kept getting a URL error and tried every variation of the switches that I could think of - but that's another blog for another time), so I opted just to use CA's backup feature.

Update 6/27: The format for exporting a list is as follows:
export-spweb -identity <URL> -path <drive location> -itemurl lists/<listname>

Once the list was exported, I imported it into a test site that I created on the same web application.  I didnt want to re-import into the user's site at this point because it would just overwrite the list instead of creating a duplicate. Not to mention the export/import took forever because there was so much content.  I wanted to clean up the data first.

Once I had the entire list moved to my test site, I deleted all the content that was no longer needed, retaining only the items that were required for the new list.  This dropped it down to under 200 items; much more manageable.  Now that the content was reduced significantly, I was able to save the list as a template with content, and simply use that template to create the new list in the original site.  Voila.  Done.  Where's the EASY button?

But you know, this got me thinking: what if the site content was still too large to create a list template with content?  If I tried to re-export and import the new list into the original site, would I run into a duplicate GUID issue even if I rename the list name & URL?  I couldnt find much information online, and I wasnt sure, so there was nothing to do but test and document my results.

Back in my test site, the first thing I did was export the newly cleaned up list.  This was now my original control list.  I then opened the test site using SharePoint Designer and renamed the original list and its URL.  I then went back to the test site in the browser to make sure the URL and the title of the original list was now changed.  I also modified the data enough so I could tell if it was overwritten. I then re-imported the list to the site.

Will SharePoint overwrite the original list anyway because of the GUID or will it put it in as a new list since the URL and name has changed.  All bets in!

You want to know what happened?  Drum roll Please.......

The SharePoint import brought it in as a new list.  The test was successful.

So if you need to duplicate a list that is huge and you cant do the list template with content way of things, this is good to know.  Enjoy!


As always, your feedback and comments are welcome in the section below.

Password complexity gets complicated with AD Trusts

I came across an issue recently in a customer's SharePoint 2010 farm.  We were performing our annual service account password changes and ran into an issue.  The people picker in our DMZ stopped working and the service account that handles that authentication kept getting locked out.  Unless the account was already cached in the user information list, new user accounts could not be queried and the address book feature was broken as well.

Because we have a AD trust set up, we have to run the following command to restore the credentials:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv "forest:web.net,domain1\svcacct1,password; forest:web.dmz,domain2\svcacct2,password" -url http://yourwebsite 

Even after running this, the people picker still did not work.  It got me thinking about the complexity of the password.  We actually had semi-colons and commas in the password for one of these service accounts, so when the command was run, it was picking up these special characters as part of the command, instead of part of the password.

After changing the password to remove these special characters, I was able to re-run the command and the password took successfully.  We then unlocked the accounts, performed an IISRESET, and BAM! the people picker again started working.

So keep in mind when choosing the complexity of your passwords.  We want to be secure, but there are some instances where special characters should be avoided.  My preference is to not use the following characters for service account passwords, particularly if you like to use powershell cmdlets:

$ - can be mistaken for a variable
; - is often used in a string to separate sections
, - same as above
Lastly, I try to avoid capital Os because they can get mistaken for a zero.

Hopefully this helps.