"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.

SharePoint Wiki Library View Issue

A coworker encountered something very strange a few days ago, and I thought it warranted a blog post.  He was migrating documents from a SharePoint 2010 document library into a SharePoint 2013 library.  He noticed that after he moved the files, when he would click on the link to the new library, the default view would actually show up as a wiki page, instead of simply listing the contents of library.  He tied changing the default view and playing around with the library settings, but nothing helped.

When I took a look at it, I noticed that there was a document that was moved to the library called "home.html".  That's when it clicked.

In SharePoint 2013, if you are using a wiki page library and there is a page in the library called "home" or "default", the wiki will default to opening this page from all site contents, instead of the all pages list view.

This would also apply to the Site Pages library.  If you have a page stored with the name "default", it will automatically pull this page up instead of the library. Simply rename this file to something else, and the link to the site pages will work correctly again.