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.

SharePoint 2010: Migrating a Sub-Site to a Different (existing) Site Collection

I decided to write this blog post because I screwed up today.  Yes, even good guys have bad days and nobody is perfect, even though to our customers and clients we appear to be.  So, slightly embarrassed for my mistake, I'm putting this out there so others can hopefully learn form this incident and avoid creating more problems and work for yourself.

I was asked by a customer to move some sub-sites from one site collection to another.  The reasoning was because he was running out of space in his storage quota and wanted to move these sites to a different content database.  This is not a big effort usually.  It's actually quite simple using powershell.

First step is you export the original site per this technet article (http://technet.microsoft.com/en-us/library/ff607895(v=office.15).aspx):

Export-SPWeb <URL> -Path c:\site_export.cmp -NoFileCompression

Once the file is created, you simply import the site to the new location (http://technet.microsoft.com/en-us/library/ff607613(v=office.15).aspx):

Import-SPWeb -Identity <URL> -Path c:\location_of_export.cmp -NoFileCompression

When you've confirmed everything looks good in the new location, you can delete the site from the original location and you're done.

BUT... HERE IS WHAT THEY DON'T TELL YOU....

You can also use Import-SPWeb to import a SharePoint list too.  The difference is, when you use this cmdlet to copy a SharePoint list, you simply specify the root site URL and it will create the new list or library in that location.  If you use this cmdlet for a site however, you MUST FIRST create a placeholder site in the destination web application.  If you only specify the root URL, it WILL OVERWRITE that site, instead of creating a new sub-site.

What made this issue even worse for me was, the original root site was created using a 'blank site' template (STS#1) and when I overwrote it, the site was changed to a 'team site' template (STS#0).  Not a big deal, right?  Wrong.  When I tried to restore the site back using an export/import from an unattached backup copy of the content database, it wouldnt overwrite the site back from team site template to blank site template.  Fortunately the site was more or less a placeholder, so I was able to fix it manually, but it could have been much, much worse.

So take it from me, always double check your cmdlets and never assume that Microsoft will be consistent in their processes.  You have been warned.

What to do when a User Profile is out of sync with Active Directory

Frequently I will get a report from a user that a user profile is out of sync or doesnt display correct information.

The first thing I do is query AD to make sure that it contains the correct information.  If AD is correct but the SharePoint User Profile is incorrect, you can try to force a full synchronization.  But if this is not successful, here are a couple other things you can try:

1) Use PowerShell Cmdlet to force a sync with AD
Set-SPUser –Identity <domain>\<username> –SyncFromAD –Web http://<webapp>

2) Manually delete and immediately re-add the profile in Central Administration.  This will force the profile service to query AD and populate with the correct information. There are no worries to delete the profile in UPS, because it wont delete the user from any site collections or lose any metadata.  It will simply re-build their profile.

3) If all else fails, you will need to remove the user from SharePoint Site Collection and re-add them.  Please keep in mind that this will remove them from any security groups they may have been added to.  All original permissions will be lost and you will need to re-add them to each of these groups and sites manually.  Use this step with EXTREME caution.

For this, navigate to the User Information List by adding "_layouts/people.aspx?MembershipGroupId=0" to the end of your site collection URL.  Select the user you wish to remove, and click Delete User from Site Collection.

Create web applications that use classic mode authentication in SharePoint 2013

In SharePoint 2013 Central Administration, you can only configure claims-based authentication when you manage web applications.  If you are migrating from a SharePoint 2010 environment where classic-mode authentication is being used, you will need to first create a classic-mode web application in SharePoint 2013, migrate all content, and then upgrade to Claims-Based, to take advantage of server-to-server authentication and app authentication as well as Office Web Apps.

Using SharePoint 2013 Management Shell with an account that has proper permissions to SQL and the farm, use this cmdlet:

New-SPWebApplication -Name "NewWebApp" -ApplicationPool "NewWebApp1.AP" -AuthenticationMethod "NTLM" -ApplicationPoolAccount (Get-SPManagedAccount "webappserviceacct") -Port 443 -Url "https://url.domain.com" -SecureSocketsLayer -DatabaseName "WSS_Content_WebApp_Root"

For more information, visit: http://technet.microsoft.com/en-us/library/gg276326.aspx