Thursday, October 9, 2014

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







#call the function 

Get-OldDocuments "" | Export-Csv -NoTypeInformation -Path C:\temp\OldDocuments.csv

Thursday, September 18, 2014

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

Friday, August 8, 2014

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 ##
[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

Wednesday, July 16, 2014

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"

Thursday, June 19, 2014

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.

Thursday, May 29, 2014

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

Tuesday, May 13, 2014

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.

Thursday, March 27, 2014

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 (

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

Once the file is created, you simply import the site to the new location (

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.


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.

Friday, March 14, 2014

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.

Thursday, March 6, 2014

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 "" -SecureSocketsLayer -DatabaseName "WSS_Content_WebApp_Root"

For more information, visit:

Wednesday, February 26, 2014

Collapsing Multiple SharePoint 2010 Web applications into a single SharePoint 2013 Web application using Host-Named Site Collections

At a client site, I was tasked to migrate a SharePoint 2010 farm from antiquated physical hardware to a new SharePoint 2013 farm in a virtual environment.  In the existing SharePoint 2010 farm, there are several web applications separating different projects.  This was done to isolate them from each other and provide more granular security.  As we should all know by now, Microsoft's best practices within SharePoint 2013  is to use less web applications (limit of 20 web applications per farm) and implement host-named site collections to create multiple "zones" or to use unique URL headers.  Side Note: If you want to learn more about Software boundaries and limits for SharePoint 2013 , visit:

So began my effort to collapse multiple web applications from a SharePoint 2010 farm into a single web application in a new SharePoint 2013 farm.

Step 1: Identify possible duplicate URLs
The first step is to identify all of the sites within an existing web application to see if any of them have identical URL paths.  For instance there may be a site "/sites/sitecollection1" and in both web applications. I like this little PowerShell cmdlt and use it quite frequently to see how our site collections are growing on a monthly/annual basis:

Get-SPWebApplication | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select Title, URL, ID, ParentWebID | Export-CSV C:\filename.csv -NoTypeInformation

Step 2: Create Web Application
The next step is to create a new web application (if one doesn't already exist in the new farm).  Depending on your authentication method, you can either use Central Administration (claims-based) or PowerShell (classic-mode).  In our case, I needed to create the web application in classic mode and then convert it to claims after everything has been moved over.  This was due to the fact that we were using Office Web Apps which requires claims-based authentication.  Here is the cmdlet used to create the web application in classic-mode:

New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>

Side Note: For more information about classic-mode authentication, visit:

Step 3: Create Empty Root Site Collection
Next, we need to create the top-level site collection.  This is a requirement for any new Web Application.  Also, this will be the only site collection that shows up in the content source.  Even though all other host-named site collections do not appear, by default search will automatically crawl them.

New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'

Step 4: Create Host-Named Site Collections
You must use PowerShell to create a host-named site collection, although you can manage it with Central Administration after it has been created.

New-SPSite '' -HostHeaderWebApplication 'http://<servername>’ -Name 'Portal' -Description 'Customer root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'

Step 5: Migrate existing SharePoint 2010 Content Databases to new Host-Named Site Collections
In the interest of staying on topic, I have skipped the steps that include attaching the content database(s), running the pre-upgrade check and testing the spcontent database.  for more information on upgrading SharePoint 2010 databases to 2013, visit this site:

Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>] [-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]

Side Note from Author: Due to an unexpected time crunch, I decided to not collapse the web applications as part of the migration.  I was hoping to be able to provide additional lessons learned and more information from actual experience, but unfortunately this is as far as I got in the production environment.  Regardless, I wanted to document a few of these steps in case we decide to revisit this again in the future or on another contract.

Wednesday, February 5, 2014

Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 1

Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 1

There are several sources online that can assist with a new SharePoint installation, however until SP1 is released, Microsoft is not supporting installation on Windows Server 2012 R2.  I have captured my lessons learned through an actual production installation that will hopefully prevent many of you the frustrations and headaches I've experienced throughout this process.  I have focused more on the initial setup errors because getting over this hurdle is 90% of the effort.  After this, everything is just a straight forward installation and tailored configuration to your environment that I'll put into PART TWO of this blog.

I will assume you already have Windows 2012 R2 installed and a functioning Active Directory structure.  I will not go into planning or architecture, but we'll agree that this installation/configuration will be done for a multi-tier (3) farm.  I will also not address installing/configuring SQL Server in this blog (see my other blog post titled: Installing SQL Server for SharePoint 2013 - coming soon)

STEP ONE - Setting up Initial Service Accounts

The following service accounts are (at a minimum) needed for installing SharePoint bits:

Setup & Install Account

  • This account must be a domain account and is used to install and configure SharePoint 
  • This account must be member of Local Administrators Group on the server 
  • This account must be assigned “dbcreator” and “securityadmin” server roles on SQL Server

Farm Account 

  • This account must be a domain account and is used to access databases and administering 
  • All the permissions required for this account will be automatically granted after completing SharePoint Farm SharePoint Farm Configuration Wizard
In the next part of this blog, I will address additional service accounts that will be needed for further configuration and customization of SharePoint 2013.

STEP TWO - Adding Server Roles & Features

If you have an Internet connection, use these cmdlets to add the necessary server roles and features for front-end web servers and application servers in the farm.
(estimated time: 30-45 minutes per server)

Online method (as described in 

Open an elevated Windows PowerShell prompt on the SharePoint server (that is, Run as Administrator), and execute the following commands:

Import-Module ServerManager

Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45

Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Application-Server,AS-Web-Support,AS-TCP-Port-Sharing,AS-WAS-Support, AS-HTTP-Activation,AS-TCP-Activation,AS-Named-Pipes,AS-Net-Framework,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer -source d:\sources\sxs

The reason I recommend using PowerShell in this instance is because when you use the PrerequisiteInstaller.exe, it will execute this Windows PowerShell code to install the Roles and Features to configure Windows Server 2012 for SharePoint 2013. Part of the Windows PowerShell code for Add-WindowsFeature installation installs the Windows NET-Framework-Core feature that is the Microsoft .NET Framework 3.5. This feature installation requires binaries and other files that are not included in a default installation of Windows Server 2012. because of this, you may get an error using the GUI and will need to point to the installation source files Windows 2012 R2.

If the server does not have an Internet connection, the PrerequisiteInstaller.exe cannot continue past the "Configuring Application Server Role, Web Server (IIS Role)" phase, and you may receive the following error message:

The 0x800F0906 error code indicates that the computer cannot download the required files from Windows Update.  In Windows Server 2012 and Windows 8, the .NET Framework 3.5 is a Feature on Demand. The metadata for Features on Demand are included in Windows Server 2012 and in Windows 8. However, the binaries and other files that are associated with the feature are not included. When you enable this feature, Windows tries to contact Windows Update to download the missing information to install the feature.  The network configuration and how computers are configured to install updates in the environment can affect this process. Therefore, you may encounter errors when you first install such features. 

For more information about error codes that may occur when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012, see the following Microsoft Knowledge Base article:
2734782 Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012

STEP THREE - Install the Prerequisites

Normally just running the PrerequisitesInstaller.exe will work, however in our environment, we had the servers configured to use WSUS instead of Windows Update, so I was getting the following error:SharePoint 2013 Pre requisites install fail, Error: The tool was unable to install Application Server Role, Web Server (IIS) Role.  This is more or less the same error you will receive in the previous section, except for a different (but same) reason.

If you come across this issue, there are 2 ways to solve the issue.  If it's an issue with connecting to Windows Update, you may need to set the following Local Policy:
1. Windows Start

2. Run MMC

3. Click File, Add/Remove Snap-in…

4. Select Group Policy Object Editor and ADD it

5. Navigate to Administrative templates / System

6. Select and edit “Specify Settings for optional component installation and component repair”
Enable and select “Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS)”

7. Re run the prerequisite installation
If this still doesnt work, your only other option is to manually install the prerequisites:
1. Download all prerequisites from the Internet and save it on local disk of the server, e.g. C:\SP2013Prereqs

SQL Server 2008 R2 SP1 Native Client
Microsoft WCF Data Services 5.0
Microsoft Information Protection and Control Client (MSIPC)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Identity Extensions
Windows Server AppFabric
CU 1 for AppFabric 1.1 (KB2671763)

2. Install all prerequisites directly from the prerequisites folder in the download sequence, EXCEPT AppFabric and CU 1 for AppFabric.

3. AppFabric requires special configuration using following statement from command line:WindowsServerAppFabricSetup_x64.exe /i CacheClient","CachingService","CacheAdmin /gac

4. Install AppFabric1.1-RTM-KB2671763-x64-ENU

5. Restart your server

At this point, you should be able to install the SharePoint Server 2013 bits on all web-front ends and application servers without any errors.

(see my next blog post titled: Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 2 - coming soon)

Friday, January 17, 2014

Underscores: SharePoint 2010 Search Worst Enemy or Just a Lesson in Futility

This is a really interesting topic.  I'm hoping that I get some feedback on this blog post based on others experience with SharePoint Search.

At a customer site, we have been troubleshooting a search problem where users were not getting any search results from within a site or a list/library, even when you could clearly see the name of the document contained within it.  We are confident that the Search Service is properly configured (because it is working fine on other sites within the farm) and we confirmed that it is running regular incremental crawls.

The more we dug into the issue, we discovered that it appeared that it had something to do with underscores in the name.  It was quickly apparent that any file under a folder that had an underscore, would not show up in the search results.  This made us question how Microsoft designed their search (why would names with underscores be ruled out?), so we created two test site collections (one created with an underscore in the site name and a second without) so we could test out the search in the following 3 scenarios:
  1. Create a Document Library with an underscore in the name (underscore_library)
  2. Create a Document Library with no underscore (regularlibrary)
  3. Create a Document Library with a space in the name (space library)
Within each of those document libraries, we created 3 folders:
  1. Folder with an underscore in the name (underscore_folder)
  2. Folder with no underscore (folder1)
  3. Folder with a space in the name (space folder)
And within each of those folders, we created two test documents:
  1. Document with an underscore in the name (document_1)
  2. Document with no underscore (document1)
We then ran a full crawl and searched at the site level for a keyword contained within the document.

Wouldn't you know... all our search results showed up?  But we thought it was a problem with the underscores, how could this be???

Ok, we thought, maybe it's one of those things that just needs to get kicked once in a while.. you know... Have you tried turning it OFF and back ON again?

So we decided to run a full crawl on the content source for the user's sites and just like that, all search results then showed up!  I was both elated and disappointed at the same time.  I was happy because the user's search results were now being displayed (and we could mark this ticket closed).. but I was disappointed because this blog post that I had been writing (and the effort to create test site collections) was for naught.

Even though this did the trick for the issue at hand, the question then becomes, what event or change happened to the site and/or the content that would cause it to not get picked up in the incremental?  We did experience a SAN crash last year (after this data was originally created) and this caused us to have corrupted databases that needed to be repaired, but we were not sure this was the reason these files were not getting picked up by the index.  We were at a loss, but I guess sometimes you just have to accept that a "reboot" will often times fix weird Microsoft problems like this and just move on.  No sense burning off a bunch of brain cells to figure every little thing out.  It works - you're a hero - now move along.

I'm always open to ideas, suggestions or perhaps your own experience with similar funky search issues like this one.  I decided to still post this to hopefully remind everyone that sometimes the best solution is the easiest.

If you want to learn more about planning for crawling and federation in SharePoint 2010, we referred to this technet article:

Until next time... stay thirsty my friends!

Thursday, January 16, 2014

SharePoint 2010 Search Issue: No Search Results for Users in a One-way Trust Domain Scenario

I just wanted to write a quick blog post about an issue we experienced this week in our enterprise SharePoint 2010 environment while it was still fresh in my head.

Even though our search service is configured properly and successfully crawling all the necessary content sources, we were getting complaints from our end-users that they were not getting any search results.  I could performed the same search query they were on the same site and I would get all the results.  So why is this happening?

Well, this is the point in time where all good SharePoint admins reach in their toolbox and pull out the biggest hammer they can find.  That's right, we did a Google search (or Bing if you're not into the whole brevity thing).

Anyway, we stumbled on THIS blog from Matt Stratton dated June 1, 2010.  He explains how to configure SharePoint 2010 Search in a one-way trust scenario.  This described our environment to a "T".

So we dug a  little more.... Then we found this article:


Once we ran the script and performed a full crawl, these users tested their sites again and search was working correctly.  They received results from their site search and everyone in the kingdom was happy.

The End!

Monday, January 13, 2014

How To Extract a Farm Solution from SharePoint 2010

I found this useful today.  I need to decompile a solution that was created by someone else and globally deployed to our production farm.  I did not have the original .wsp file, so I had to extract it from SharePoint using these 3 lines of code:

$farm = Get-SPFarm
$file = $farm.Solutions.Item("global.deploy.solution.wsp").SolutionFile

Note that in order to run this command, you need to be a member of the Farm Administrators group and have permission to the configuration database.

Monday, January 6, 2014

Migrating a Single Sub-Site from a MOSS 2007 Farm to an existing SharePoint 2010 Farm

I was recently tasked to migrate a single sub-site from a degraded MOSS 2007 farm to an existing SharePoint 2010 farm.  The existing MOSS 2007 sub-site is contained within a single content database, in a single site collection with over 2500 other sub-sites.  The task was to migrate just the one single sub-site, so here are the steps I took to accomplish this move, using the Database Attach method.

  1. Create a new content database in the MOSS 2007 farm.  This was accomplished through SharePoint 3.0 central Administration.  It's a pretty straight-forward process.  I did this so I had a clean database to move that only had the data I needed.
  2. Create a new site collection in the new content database within MOSS 2007.  Again, a straight-forward process using SharePoint 3.0 Central Administration.  I mimicked the managed path that I wanted to use in the SharePoint 2010 environment.
  3. Open Command Prompt and change directory to %COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin, then run the following STSADM command to export the content of the site:
    stsadm -o export -url <Old Site URL> -filename <export file> -includeusersecurity -versions 4 (to include all versions)
    More information about stsadm export/import can be found HERE
    It's important to make sure you have enough available disk space for the backup files.  You can verify the size of the site by opening it up in SharePoint Designer (2007 in this case) and clicking Site > Reports > Site Summary

    If you get an error during the export process (Error: Unknown compression type in a cabinet folder), it means you have insufficient disk space available.  Please keep in mind that it will write temp files to the C drive, so make sure you have at least 2-3x the total storage needed, or save the back up files to a different drive to split off the load.

  4. Once the content has been exported, use the following STSADM command to import the content of the site to the new site collection on the new content database:
    stsadm -o import -url <New Site URL> -filename <export file> -includeusersecurity

At this point, we have isolated just the content we need into a new MOSS 2007 content database, which will make the move much easier than it was before we started.  If you run into any problems with the above steps, make sure the account you are using has the necessary permissions.  

Before we create a backup of the 2007 content database and move it to the new 2010 farm, we will need to run the Pre Upgrade Check and fix any issues reported before moving on to the next step:
stsadm -o preupgradecheck

Once the database is ready, it's time to create a backup the database and copy it over to the new SQL instance:
  1. Open Microsoft SQL Server Management Studio for the 2007 instance. Right-click on the content database and select Tasks > Backup...
  2. Enter the Backup Name, select Destination, and click OK to start.
  3. Copy this backup file to the SharePoint 2010 SQL server.
After the database is in the new environment, restore, test and mount the database to SharePoint 2010:
  1. Restore the SharePoint 2007 backup to SharePoint 2010 SQL Server. Open Microsoft SQL Server Management Studio. Right-click on Databases and select Restore Database...
  2. Enter the new database name, making sure that you don't overwrite the original content database. Select the Source and click OK to start.  If the database is showing "offline", be sure to bring it online before moving to the next step.
  3. Next, test the database against the existing SharePoint 2010 web application.  If there are any errors, make sure to correct them before mounting the SP2007 content database.
    Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>
  4. If there are no errors (or the errors have been fixed), use the Mount-SPContentDatabase cmdlet. This cmdlet also upgrades the SP2007 content to SP2010.
    Mount-SPContentDatabase <ContentDb> -WebApplication http://SiteName
    If the database was moved from a different environment, you may need to change the site collection administrators in order to see the Site Settings menu
  5. Verifiy the data is moved properly and perform visual upgrade.